B-Free メイリングリストの皆さん、こんにちは。
# 以下の文では、Open VMS のことを書いた部分がありますが、
# Open VMS については共立出版から出ている OS シリーズの
# 「Open VMS」を読んだだけですので、正確かどうかはちょっと
# 自信がありません(そのため、「ようです」とか「でしょう」
# などの曖昧な言葉が多くなっています)。内容が間違っているか
# もしれないので、Open VMS の詳しい人がいたらコメントください。
>> On Tue, 11 Apr 1995 00:06:00 +0900, 真鍋 さん said:
>> ファイルシステムマネージャは、デバイスをファイルシステムに接続
>> するときに、他の処理にはデバイスをアクセスできないようにロック
>> を行うと思いますが、その点はどうお考えでしょうか?
>> それと、ファイルシステムを介さずにメモリマネージャが直接デバイ
>> スにアクセスした場合、ファイルシステム側からみると実行ファイル
>> をアクセスしているもの(プロセス/周辺核)がいないということにな
>> り、実行中の実行ファイルの内容が変更されてしまうという危険性は
>> ないでしょうか?
>>
>> VMS の場合には、どうも OS にはファイルシステムというものがな
>> く、ライブラリでファイルシステムを管理/構成しているようで、この
>> 問題はないみたいですが。(この辺の理解にはちょっと自信がない。。。)
> あらためてVMSの解説を読むと、I/Oサブシステムというマネージャに相当する
> プログラムを通じてディスク入出力を行っていますね。(通常のディスクI/Oと
> は別の要求受付口が存在し、高速に処理を行うとある)
えーと、Open VMS (共立出版) を読んでいない人のために、ちょっと註釈:
Open VMS では、システムが4つの層に分かれていて、おのおのカーネル/エ
クゼクティブ/スーパバイザ/ユーザという風な名前がついています。
Windows/NT でもエクゼクティブという層がカーネルの上にありますが、ど
うやら、名前を Open VMS から引きついでいるみたいですね(まぁ、作った人
がほとんど同じだから当然か??)。
真鍋さんの書いてあるように I/O サブシステムというのが入出力を管理し
ています。I/O サブシステムはこれらの層の一番中心、カーネル層にあります。
面白いことに I/O サブシステムではデバイスへのアクセスを行うだけで、ファ
イルを扱うのは RMS (レコードマネジメントシステム)というサービス関数(?)
が行っているようです。RMS は層としてはカーネルよりも外、エクゼクティブ
層にあります。
残念なことに、エクゼクティブが独立したプロセスとして動いているのか、
それともユーザプロセスのコンテキストで動いているのかは、はっきりと書い
ていません。ただ、各層の移行を行うのに、専用の命令を使う(Alpha AXP で
は PAL)とありますから、独立したプロセスというわけではなく、ユーザのコ
ンテキスト内で動くようです。
> メモリマネージャがデバイスを直接操作すると、プログラムとしての信頼性が
> メモリマネージャとファイルマネージャの両方に要求されるなど、難点の方が多
> くなると思われるので、メモリマネージャがデバイスを直接操作する案は撤回し
> ます。
> これに伴って、アプリケーションの実行コードをクラスタ単位にアクセスする
> 案も撤回します。
はい、分かりました。
>> それに、回復処理にかかる時間にしても、実行ファイルが頻繁に実行
>> されるとするとファイルシステムのキャッシュに残る可能性が高くな
>> ります。逆にファイルシステムを介さないとキャッシュを介せなくな
>> りますから、むしろ遅くなる場合がでてくるでしょう。
> このあたりについては、メモリマネージャのページメモリ管理の中で、キャッ
> シング効果を発揮するような渾然一体とした機構が実現されるものと、勝手に想
> 像していました。(^^;
> (VMSはページ領域管理のなかで、ディスクキャッシュと同様な効果を生み出して
> います。WinNTのNTFSでは、キャッシュファイルを仮想空間にマッピングすると
> あり、詳細はわかりませんが仮想メモリを利用してディスクキャッシュを実現す
> るらしい。)
メモリマネージャがキャッシング操作をすることについては、いいところと
悪いところがあって、私自身としては決めかねています。
たとえば、メモリ管理とファイル管理が一体となっているような OS では、
メモリ管理が使っていないメモリ領域をファイル管理がバッファとして使用す
ることができます。たとえば、UNIX などのすべてがひとつのカーネルという
大きなプログラムで管理してような OS では、バッファの内容をそのまま仮想
メモリにマッピングするというようなこともできます。
B-Free OS のようにメモリ管理とファイル管理を別々のタスクが管理すると
した場合、メモリマネージャがメモリすべてを管理してしまうと、ファイルマ
ネージャがバッファリングできなくなってしまいます(逆も同じ)。限られた実
メモリという資源をどうやって管理するのが一番良いのか。。。
そこで、Open VMS はどうかと、先の本を参照したところ Open VMS では、
使っていないメモリをフリーリストとモデファイドリストというリストで管理
していて、リストの大きさが一定量を越えるとディスクに書き出すというよう
になっているみたいです。つまり、ファイル管理のバッファリングは別にある
というものみたいです。どうも、Open VMS では各要素が使うメモリというの
が精密に分配されているようです。プロセスごとに必要なメモリ量 (ワーキン
グセット) というのがあって、その量を越えると余った分がページアウトされ
るようになっています。システム全体では、各プロセスのワーキングセットの
合計がユーザプロセスのために使用される実メモリ量となり、それ以外のメモ
リは、キャッシュなどの役割に分配されるのでしょう。
その逆に UNIX などでは、ユーザプロセスのもてる実メモリには制限があり
ません(仮想メモリの使用を制限することはできます)。メモリをたくさんアク
セスするユーザプロセスがあったら、実メモリもその分多くとれてしまいます。
ページアウトは、システム全体で考えているので、各プロセスのもつ実メモリ
量はかなりアンバランスなものとなります。(実際のメモリの使用量に見合っ
たものといえないこともないですが)
Open VMS の方は、どちらかというと資源管理を厳密に行うことを考えてい
るのに対し、UNIX の方は資源の使用に制限をあまり加えないという方向にいっ
ているように思えます。この違いはやっぱり、企業と大学という生まれの違い
きているのでしょう。UNIX では、使用者が他人に迷惑をいくらでも(かけよう
と思えば)かけられるのに対し、Open VMS では、そういうことができないよう
に OS で監視しています。もっとも、UNIX はサーバとして働くようになって
きましたから、将来は資源管理をきっちりしていくように変化するのでしょう。
>> それとも、ページフォールト時に仮想メモリを確保するということを
>> 意味しているんでしょうか?
>> そうした場合、本当に仮想空間が足りなくなるというのはメモリをア
>> クセスした時にしか分からないという問題があります。
>> つまり、ユーザプロセスから見ると確保したはずのメモリをアクセス
>> すると、(仮想空間が不足して)メモリアロケートエラーになるという
>> ことになります。
>> こういう方式というのは、ユーザプログラムから見てかなり使いにく
>> いシステムのような気がします。
> その方法を考えていました。
> スワップ領域は必要十分な大きさがあり、その使用割合が一定の割合を越えた
> 時点で、何等かの警告を発生させる程度で考えていました。
> ギリギリの状況だと、スワップを確保しようとした時点で突然にプロセスが停
> 止するケースもありますから、プログラムから見ると確かに不親切ですね。
確かに、スワップ領域(正確には、システム全体の仮想空間)の空いているペー
ジの割合が一定量を下回ったら警告する必要はありそうです。そのためには、
マネージャがユーザに対してメッセージを表示する仕掛が必要となりますね。
せっかくですから、メモリ不足のためだけではなく、システムで統一した(警
告)メッセージ表示機能を作りたいですね。
ということで、マネージャのメッセージ表示についての機構についてアイデア
を募集します ^^。> all
何かいいアイデアはないでしょうか?
-- 内藤隆一 (ggc00661@niftyserve.or.jp)