I/Oシステムについて
I/Oに関しては、デバイスドライバ(その7～その9)(*1)の所で流れを説明しているから、ここで蒸し返しなおす必然性はあまり無いだろう。
ここで触れなかった項目で、VMSと類似のものには高速I/O(下巻P95～)がある。デバイスドライバの基本的奈動作はこちらで説明した通り、I/O ManagerがStart I/Oルーチンを呼んでI/Oを開始し、完了後はISRからDPC経由で再びI/O Managerが呼び出され、最後にUser ACPを呼び出して終わる形である。当然ながらこれはオーバーヘッドが非常に大きい。特にIRQLが上下したり、Kernel内部でContext Switchingが発生したりQueueが動いたりするわけだから、少なく済むはずも無い。もっとも通常のI/O要求に関しては、「それがOSを使うことのデメリットである」で済ませられない訳でもないが、唯一File I/Oに関してはそうも言ってられない。特にPage FileのI/Oに関しては、これが遅いとシステム全体に影響を及ぼす事になるからだ。だからといって、「PageFileに対するI/Oは優先的に処理する」なんてインプリメントを実施するのは、実際には簡単ではない。ハードディスク1つ取っても、Windowsでは様々なものを取り扱う。オンボードのPATAをLBAでアクセスする場合とCHSでアクセスする場合では最適化アルゴリズムが変わってくるし、SATAのNCQが使える場合とかSCSI系の場合、あるいはRAIDコントローラの場合などで、全部異なるアプローチとなる。例えばLBAの場合、シーク順を考えてI/Oの順序を並べ替える、というのは現実的にあまり意味が無い。が、古いCHS形式ならこれには意味があるし、NCQをサポートしたSATAディスクならば、ドライバが一部これを行ってくれる。そうなると、例えばPage FileへのRequestが来たら、現在処理中のものを全てキャンセル&改めてキューイングし直し、Page FileのRequestを実施するなんてインプリメントは却って遅くなる可能性がある。キャンセルはしないまでも、次の処理の先頭にPage FileのRequestを突っ込む、なんてのもNCQが使われている場合は逆効果だ。
そこでこういう難しい事を考えずに、「とにかくオーバーヘッドの少ないI/O手段を用意して、Disk I/Oの一部をこれで賄おう」というのが高速I/Oのコンセプトである。高速I/Oにおいては、I/O ManagerからIRPを介さずに直接Start I/O Routineを呼び出し、かつDPC RoutineもI/O ManagerにIRPを戻さずにPost I/Oの処理を行ってくれる。これにより、大幅にI/Oのオーバーヘッドが減るというものだ。
これが何に似ているのか? というと、プロセスその11でちょっと触れた、Connect-to-Interruptという技法である。こちらもSYS$QIOを使う通常のI/O処理ではなく、まずデバイスを叩いて処理を開始し、完了のInterrupでUser ISRを立ち上げ、その中でPost I/Oを全部行ってしまうという荒業であるが、やはり処理のオーバーヘッドが非常に少ない技法だった。I/Oを高速化しようとした場合には、こうしたやり方が常道だとも言えるかもしれない。
もっとも、VMSにおけるConnect-to-Interruptはかなり切羽詰った場合の切り札であって、常用するようなものではない、とされていたのに対しWindowsにおける高速I/OはFile I/O、厳密に言えばキャッシュとFileの間のコピーに常用されている点が大きく異なる。具体的なインプリメントとか使われ方は11.6の高速I/O(下巻P232～)に詳しいのでここでは割愛するが、対象をDisk I/Oに限り、かつSystem Cacheとの間のコピーに限るという使い方をすることで、多用しても問題ないと判断したのだろう。VMSのConnect-to-Interruptは汎用の技法でどんな用途にも使えるからこそ、上述の縛りが付いたのだとも言える。
その他の項目に関して言えば、例えば電源管理とかPnPといった項目は勿論VMSには無かったから、これらはWindows NTの開発の際に新規に追加された項目となる。もっと言えば、Windows NTにPnPや電源管理がちゃんとインプリメントされたのは1996年に登場したWindows NT 4.0で、それ以前のバージョンではそもそもインプリメントされていなかった。実際PnPに関して言えば(このあたりでも触れたが)PnP ISAは殆ど使い物にならず、まともに動作するようになったのはPCI、それもカードスロットの仕様がちゃんと決まったPCI 2.0がリリースされた1993年以降の話である。Windows NT 3.1のリリースが1994年だから、初期バージョンにPnPのインプリメントが間に合う筈が無い。このあたりはWindows NT自身にPnPや電源管理の仕組みを追加しつつ、ドライバを拡張してこれのサポートを行わせるという作業がバージョンアップ毎に行われていた訳で、VMSとの共通点があったらそのほうがどうかしているとも言えるだろう。
(*1)今読み返して気が付いたのだが、なぜか「デバイスドライバその2」という番号が飛んでおり、その1/3/4となっている。単なる番号の振り間違いなのでご容赦いただきたい。
