Linuxの仕事、思わぬ伏兵が最後に待ちかまえていた。

Linusがcomp.os.minixでLinuxの公開をアナウンスした時に居合わせた世代だけど、その頃は皆競ってフロッピー一枚に入ったLinuxのイメージをあちこちのPC AT互換機のフロッピードライブに入れて試しだしたのがLinuxブームの始まりである。

当時試したDELLのマシンはフロッピー制御のタイミングが早すぎてブートしなかったのを憶えている。いろいろとハードウェアの相性というかタイミングは千差万別だというのがわかった。

LinuxはPOSIXという当時IEEEとかが制定したUNIXのAPIや基本コマンド群の仕様を外部仕様として採用した。これは今も変わっていない設計思想である。しかし外側はそれで変わらないが中身は今もどろどろとサナギの様に変貌し続けて定まらない状態である。

Linux 0.99とか限りなく1.0に近づいていた頃はとても単純だったけど、PC AT互換機よりも手の込んだアーキテクチャをサポートしはじめた頃からどんどん巨大化複雑化して来た。

PC AT系のアーキテクチャはメモリが中央に固まりとしてどんとあって、バス上のデバイスやCPUがそれを共有するという、いわゆるUniform Memoryアーキテクチャであるのに対して、CPUを複数搭載した対称型マルチプロセッサシステムでは、それぞれのCPUの処理負荷が高くなるとメモリーアクセスの負荷がUniform Memoryアーキテクチャで一点に集中してCPUが互いのメモリアクセスを邪魔し合うということになり性能が出ないということが明らかになった。

そこで登場したのが、CPU毎にメモリを分離して、メモリを分断するというNon Uniform Memoryアーキテクチャ(NUMA)が登場。

でもNUMAの場合は周辺バスがCPUやメモリから遠ざかることになるので周辺デバイスがメモリやCPUとお話する場合に遠くて時間がかかるというペナルティがある。

それでも計算を早くするにはCPUに最も近いところにメモリを置くのが正解。それぞれのCPUは最寄りのメモリをアクセスする頻度が高くなればなるほど他のCPUを邪魔することなく理論的にCPUの個数に比例して処理能力も上がる。

そうしたちょっと逆説的なアーキテクチャも同じソースコードでサポートしなければならないので百年戦争のようなアイデアの戦いが今も続いている。ある人がある案をだせば別の人ももっと良い案を出して、新しい案が消えてはまた別の現れるという感じ。

久々にカーネルメーリングリストを覗いたらつい最近も今回悩まされた技術的な問題をどうゆう方向にもっていくか議論されていたようだ。

まあ、特定のアーキテクチャに関してはそれを使える人とメンテナンスやパッチを提供する人は自ずと限られるのでいずれは定まっていくのだろうけど、仕事となるとそれを待ってはいられない。

ここはオープンソースの良いところ、面倒だけどそれなりに労力を費やせば自分の好きなように修正して問題解決が出来る。

これがクローズドな商用OSだったら地獄だ。手も足も出ないだろう。

昔DECのVAX/VMSのパッチを考案しては米国DECに提案していたけど、「あ、その機能外すことにしたから」とか米国人らしい技術的な決定に唖然とすることも。日本人はなんとか機能は残してより良いものにと思うのだが、米国人は割り切りが早いので問題のある機能は削ってしまうのが一番というカルチャーの違いがあったり。

初期のVAX/VMSはそれ以前のミニコンピューターの主要な需要家だった組み込みシステムやリアルタイムシステム向けに設計されていた。売り文句もリアルタイム向きですからというもの。でも当時仮想記憶をサポートして汎用機並に大きなアドレス空間を消費する大型アプリケーション（ＣＡＤ、シミュレーター、画像処理）の要望が強くなり、次第に今で言うコンピューティングサーバーみたいな方向に進路を変えていった向きがある。決定的だったのは、V2まではスワップスペースがシステムの最大ワーキングセットサイズ＊最大プロセス数だったのが、プロセスの最大ワーキングセットサイズが可変になったのでスワップスペースのアロケーションも可変長に変わったことだった。これは何を意味するかというと、以前は最大ワーキングセットサイズ（１プロセスが使用できる最大仮想アドレスページ数）分のスワップスロットが最大利用可能なプロセス数分配列で用意すればよかったのが、可変になると全体でいくら用意してもフラグメンテーション（虫食い）状態になると全体のスワップスペース分の割に同時期に走行可能なプロセス数が制限されることになる。言い換えればV2まではどのプロセスも1stクラスで各自用に十分な個室が予約されていたのが、全員自由席、席取りは早い者勝ちということになってしまったのである。V3からそういうことになったのでいろいろ支障が出てきた。

組み込みシステムでは基本的にディスクへのワーキングセットの吐き出しは発生しないようにメモリは十分積んでいる。V2の頃は配列分ディスクスペースを用意していれば書き出されることはなくともプロセスがワーキングセットを最大値までのびのび成長させることは出来た。しかしアロケーションが可変長になると、動きはじめはワーキングセットが少ないけど、処理を重ねるたびにワーキングセットが成長し、それまでアロケートしていたスワップスペースがそれに合わせて拡張できない状況が発生し得る（前後に隣接して他のプロセスのスワップ領域がアロケートされて挟まれている場合）。

そうするとまだまだ伸び盛りなのに他にもっと大きなスワップ領域が空いていないとワーキングセット（アドレススペース）を拡大できないという問題が発生する。アドレススペースが拡張できないとページフォルトで処理が止まったままになってしまう、これはリアルタイムシステムではあってはならない事態。

実際にそういう事例や状況がいろいろなシステムで発生することが知られていたので、上司に命じられて対策を考えることにした。当時上司が考案したVAX/VMSにシステムの再起動の必要の無いランタイムにカーネルにパッチを施すことができる画期的な方法を考案したので私にその具現化の機会が与えられた、その方法をつかってスワップスペースが虫食い状態なったのを自動的に検出して、今でいうファイルシステムのデフラグメント処理みたいに、並べ替えをするコードをVAX/VMSカーネルに、今で言えばレトロウイルスを使った遺伝子操作と同じ方法だ。パッチは恒久的に施すのではなくメモリ上にのみ施す。システム起動後の任意のタイミングでパッチをあてるプログラムを自動起動するようにしておくだけ。

効果はてきめんでスワップスペースのフラグメント化ですくんだプロセスが出るとアロケーション状態を整理しなおして、大きな空きスペースを作り、成長したプロセスがそこにもっと大きなスワップスペースをアロケートして引っ越せるようにした。

まあ今のようにメモリが有り余る時代ではなく数MBも貴重だった時代なので、そういうことも有用だった。今ならディスク増やせばいいじゃんとかいう話になってしまう。当時は60MBでも大きい方だった。

なんの話だっけ。

ああ、Linuxの話ね。

これも仮想記憶に関係する根深い問題なのだけれども、カーネル中のデバイスドライバがアロケートしたメモリ空間をユーザーからもアクセスできるようにダブルマップするというのがVAX/VMSの時代から当然のごとくある。しかしLinux 2.6になってそれが大変やりにくくなってしまったらしい。というのもそれに絡んだ処理でDoS攻撃の標的になる脆弱性が見つかったらしいのもある。

でもページングとか仮想記憶の原理を知っていれば、ああなんだという方法なのだが、2.6カーネルでも出来るらしいし、数少ないけどそういうことをやっている既存のドライバもあるらしい。

それと同じことをやれば問題は解決。目出度し目出度し。まだ終わっていないけど。

朝だ徹夜だ！

そういう名前の作家が昔居た記憶が。「麻雀放浪記」昔読んだっけ。

もう夜だし、まだ一睡もしていない。