[b-free: 227] Re: Re^3:About memory mana

内藤 隆一 (GGC00661@niftyserve.or.jp)
Sun, 09 Apr 1995 23:14:00 +0900

隆一です。

B-Free メイリングリストの皆さん、こんにちは。

先日の真鍋さんから出していただいたメモリマネージャがデバイスを直接アク
セスするというアイデアですが、やはりファイルシステムを介した方がいいと
思います。

>> On Sun, 09 Apr 1995 21:05:00 +0900, 真鍋さん said:

> B-Freeミーティング御出席の皆様、御苦労さまです。
> カーネルグループの方で内容が煮詰まって来ていると思いますが、先日の内容へ
> の補足を少し。

>> ディスク上のクラスタを記録するテーブルを作成するということは、
>> メモリマネージャはコード部でメモリフォールトした場合、ファイル
>> マネージャを通さずに、デバイスドライバを通してデバイスにアクセ
>> スするということでしょうか?
>  その通りです。プロセスの生成段階でファイルマネージャからクラスタ番号を
> 受け取っておけば、ページフォルト発生時の処理が、データ領域のページインと
> おなじ処理となって、処理が単純に出来るだろうとの考えからです。

ファイルシステムマネージャは、デバイスをファイルシステムに接続するとき
に、他の処理にはデバイスをアクセスできないようにロックを行うと思います
が、その点はどうお考えでしょうか?
それと、ファイルシステムを介さずにメモリマネージャが直接デバイスにアク
セスした場合、ファイルシステム側からみると実行ファイルをアクセスしてい
るもの(プロセス/周辺核)がいないということになり、実行中の実行ファイル
の内容が変更されてしまうという危険性はないでしょうか?

VMS の場合には、どうも OS にはファイルシステムというものがなく、ライブ
ラリでファイルシステムを管理/構成しているようで、この問題はないみたい
ですが。(この辺の理解にはちょっと自信がない。。。)

>> このようにした場合、コード部分の内容はディスク上でもクラスタ単
>> 位で記録する必要があります。BTRON1のファイルシステムだとブロッ
>> クサイズ以下の断片ブロックというのがありますから、クラスタ単位
>> にコード部を記憶するのはなかなか難しいような気がします(リンカが
>> 実行ファイルを作るときに意識しなければいけない)。BTRON1 ファイ
>> ルシステム以外のファイルシステムも記録単位としてページサイズを
>> 基にするとは期待できるとは限らないのではないでしょうか?
>>
>> コード部の情報については、実行ファイルを示す情報と実行ファイル
>> 中のオフセットの記録だけでいいと思いますが、どうでしょうか?
>  この部分については、どうするべきか考えましたが、私個人としては何はとも
> あれ、ページフォルトからの回復処理が何にも増して重要であり、それが速やか
> に解消出来る仕掛けを用意する必要があるとおもって、アプリケーションプログ
> ラムのコード部については断片ブロックを認めないのも仕方無いと判断しました
> 。

実行ファイルの時のみ断片ブロックを作成しないようにするには、ファイルシ
ステム側に断片ブロックを作成しないというインタフェースを作る必要があり
ます。リンカが実行ファイルを作成するときには、単に通常のファイルとして
作成しますから、ファイルシステムが自動的に判断することはできないでしょ
う。

それと、一番の問題としてはメモリマネージャがファイルシステムの構造を知っ
ている必要があることでしょう。
ファイルシステムの種類が増えてくるにしたがって、メモリマネージャの内容
を変更するのは難しいと思いますが、、、

結局、ページフォールトからの回復処理(ページイン)の速度とシステムの複雑
度のつりあいをどこにもってくるかの問題となります。
私の意見としては、多少回復処理に時間がかかってもシステムの複雑度を下げ
る方がよいと考えます。

それに、回復処理にかかる時間にしても、実行ファイルが頻繁に実行されると
するとファイルシステムのキャッシュに残る可能性が高くなります。逆にファ
イルシステムを介さないとキャッシュを介せなくなりますから、むしろ遅くな
る場合がでてくるでしょう。それについては、どうお考えですか? > 真鍋さん

>> 領域を確保するのがページのページアウト処理を行うときの方がいい
>> という理由は何でしょうか?
>  ここで言う領域確保とは、未使用のスワップ領域からページアウト用のクラス
> タを切り出す処理を指しています。ページアウト処理を行う段階になってから領
> 域を確保した方が良いとしたのは、
> ・スタック領域の様に事前に必要サイズを正確に把握していない可能性がある。

> ・フリーメモリーが余っている段階ではページアウトする領域は必要無い。
> ・使用出来る実メモリが16MBあったとして、各プロセスが要求するメモリの
> 合計が18MBだとすると、必要なスワップ領域は2MB(+α)で済むはずで
> ある。
> と考えたからです。

仮想空間として実メモリ + スワップ領域のサイズ分存在するということです
ね。それはそれでいいと思います。

BSD でも初期の頃は仮想空間すべてをスワップ領域にしていましたが、最近は
実メモリ + スワップ領域というように変わってきています。メモリマネージャ
の処理が多少複雑になる以外には、さほど問題はないでしょう。

>  事前に領域を確保すると、各プロセスから実際に消費する以上の領域の使用が
> 宣言されて、スワップ領域が余っているにも拘らず、スワップ領域が不足してい
> ると判断され、それ以降はプロセスが起動できなくなるのではと思うのですが、
> どうでしょうか。

それは、仮想空間のサイズが実メモリ + スワップ領域となった場合でも同様で
しょう。単に実メモリの分だけメモリ不足となるのが遅れるだけです。

プロセスが「実際に」「消費する」というのは宣言された状態では不明です。
宣言した分の領域は、仮想空間を確保する必要があります。
結局、仮想空間が実メモリの分だけ広くなっただけなのだから、あまり過大な
期待はできないと思います。

たとえば、実メモリが 8 MB 積んでいるマシンを考えてみましょう。ユーザ用
として半分の 4MB が使用できるとします。そして、HD 上のスワップ領域のサ
イズが 20MB だとすると、真鍋さんの方式では 24 MB のサイズが仮想空間に
使用できます。仮想空間すべてをスワップ領域に確保するとした場合には、
20MB 使用可能ということになります。

この差は実メモリの分の 4MB となります。

----------------------------------------------------------------------

それとも、ページフォールト時に仮想メモリを確保するということを意味して
いるんでしょうか?
そうした場合、本当に仮想空間が足りなくなるというのはメモリをアクセスし
た時にしか分からないという問題があります。
つまり、ユーザプロセスから見ると確保したはずのメモリをアクセスすると、
(仮想空間が不足して)メモリアロケートエラーになるということになります。
こういう方式というのは、ユーザプログラムから見てかなり使いにくいシステ
ムのような気がします。

# 直接関係ないですが、同様にローカルメモリのアロケートにアクセスした瞬間
# にメモリを割り当てるという BTRON3 の方式というのは間違っていると思い
# ます。

-- 
内藤隆一 (ggc00661@niftyserve.or.jp)