プロセスその10
このPFN Databaseに相当するものをWindowsもやはり保持している。というか、やはり同じようにPFN Databaseという名前をそのまま踏襲している。このあたりは7.11(上巻P548～)の「ページフレーム番号データベース」に詳しいが、図7-34(上巻P550)でも判るとおりデータベースが双方向リンクで構成されているあたりは、まんまVMSのPFN Databaseといった趣である。勿論DatabaseのEntryそのものは多少異なっているが、これは両方のOSの違いが反映されていると考えるべきだ。
ついでに、図7-35(上巻P552)を元に、ページの遷移をすこしまとめておこう(なぜかIDSにはこれに相当する図が無い。昔、VMS Internalsか何かのマニュアルには、これに相当する図があったと記憶しているのだが、まぁこちらで十分説明は可能だ)。
209回目で、一定期間毎にWorking Setに属する全ページのValid bitを落としてやることで、あまり使っていないPageを見つけてPage OutすることでWorking Set Sizeを縮小するという話をしたと思うが、この際にPage OutされたPageがどうなるか、という話がこの図には関係してくる。
ちょっと繰り返しになるがもう一度考えてみたい。まずあるタイミングでそのWorking Setに属するページ全体のValid bitを落す。VMSの場合、これはWSLX Arrayを先頭から辿ってゆけば、それが全てWorking Setに利用されているPageのPFNだから、処理は簡単だ。ここから一定期間待って、もう一度WSLX Arrayを先頭から舐めてゆく。この「一定期間」が余り短いと、片っ端からWorking Setに属するPageがPage Outされてしまうし、逆に長すぎると殆どのPageがValidになってしまい、空きページを見つけられなくなってしまうので、やはり「適度」な時間間隔にすることがシステムの健全性を保つために重要であるが、今回の議論には直接関係無いのでここでは措いておく。
さて、一定期間後にもう一度WSLX Arrayの先頭からValid bitを舐めていった結果、いくつかのPageがInvalidのままだっだとしよう。そこで、このPageをPage Outすることを考える。ただし、いきなり開放するわけにはいかない。まずPageの内容をPage Fileに書き出す必要があるからだ。ただ、だからといっていきなり書き込みを開始したら、そこがボトルネックになってしまい兼ねない。こうしたものはWrite Backの形を取ることで、書き込みアクセスを最適化するというのがセオリーだからだ。
そこで、Valid bitが落ちたPageはまずWSLX ArrayからBAK Arrayに繋ぎかえられる。この状態でPageの内容をPage Fileに書き出すのを待つわけだ。このPage Fileへの書き出しをVMSではBacking Storeと呼ぶ。前回BAK Arrayの説明のところで出てきたのは、これの事である。ここでPage Fileへの書き出しが完了した場合、そのPageはこれ以上内容を保持する必要はない。そこでBAK Arrayから切り離し、FLINK Array / BLINK Arrayで管理する形になる。一方、まだ書き出しが済む「前に」そのPage参照が発生した場合、再びBAK ArrayからWSLX ArrayにPageを繋ぎなおす事になる。これにより、Page Faultのペナルティは最小に抑えられるというわけだ。
|
図1:Page遷移図(VMS) |
ここまでの話を図7-35に似せて描いたのが図1である。Working SetからPage OutするとBAK ArrayのModified Page Listに一端入り(1)、そこからBacking Storeを行ってFree Page List入りする(2)。勿論Process終了などの場合はそれをPage Fileに書き出す必要がないから、直接Free Page List入りする(3)。逆にWorking Set増加などでPageが必要になったらFree Page ListからWSLEにページが割り当てられる(4)ほか、Page Fault時にまだModified Page Listに当該ページが残っていれば、そこからPage Inする(5)という訳だ。これと図7-35を見比べていただくと、非常に良く似た構造になっていることがお分かりいただけよう(ここでZero Pageとかに関してはとりあえず無視していただきたい)。
Windowsにおける大きな違いは、Standby Page Listと呼ばれるものが追加されていることだ。これは更にPage Faultのペナルティを減らそうという試みと理解できる。つまり、Modified Page List中のPageがBacking Storeを行っても、Pageそのものはまだデータを保持している。このデータは、当該Pageが他のWorking Setに割り当てられ、内容が上書きされるまで有効だから、Backing Storeが終わってももしそのPageがPage Fault対象となったら、何もPage Fileから値を読み出して新規Pageに格納しなくても、書き出したPageをもう一度引っ張ってくれば済む、という考え方だろうと想像される。(続く)
