最新開発カーネル 2.3.17: またもや巨大パッチ

またまた、巨大なパッチです。 大量のドライバが変更されました。

また、SCSI コードをきれいにして、いくらか読みやすくしようという Alan Cox 氏の挑戦の、最初の成果も見ることが出来ます。 ただし、 これは待望されている「SCSI レイヤーの書き直し」ではありません。 単にいくらかのクリーンアップを施しただけです。 他の問題をいくつか見つけるのをはかどらせるための、、、

※ SCSI レイヤーの書き直し - SCSI レイヤーは Linux カーネル内の汚い部分の一つと言われています。 Linus を始めとして何人もの Linux ハッカーがこれを一から書き直す必要を認めていますが、 まだこの一大事業に乗り出した方はいません。

最新安定カーネル 2.2.12: メモリリーク調査中

このカーネルにはまだ、いくつかの問題が報告されています。 特に inn を走らせているシステムにおいて発生するらしい、 メモリリーク問題が未だに存在するようです。 この問題に関しては、（この記事の執筆時点で）依然として、 原因を突き止めようという努力が開発者の方々によりなされています。

（※ その後リリースされた、 2.2.13pre6 では修正されている （英語）ようです。）

カーネルリリースをもっと頻繁に --- 2.2 リリースは早すぎたけど、、、

RAID 0.90 は、 LWN 8月 19日の記事 (英語。日本語) において、 2.2.12 に組み入れられつつある、と報告されました。 ところが一週間後、 その報告はアップデートされ、 RAID パッチは取り下げられたと訂正されなければなりませんでした。 なぜでしょうか？ ユーザ向けの新しいツールが必要になる、 そのような大きな変更 を安定版カーネルのマイナーリリースに入れることに対し、 多くの方々が異論を唱えたからです。

さて、今度は、 NFS サーバパッチが同じ運命に苦しんでいるようです。

NFS サーバパッチは、 H.J. Lu 氏とその他の方々により開発され、 Linux システム上で 本格的な NFS サービスを行うサイトにとっては 必要不可欠なものとなっています。

※ knfsd は当初 Olaf Kirch 氏によって開発されましたが, その後 H.J. Lu 氏が開発を引き継いでいます。

このパッチは、新機能を一切追加しません。 ただサーバを正しく動くようにするだけです。 しかし、このパッチは最新バージョンのユーザ空間ツールを必要としてしまうのです。

RAID でも NFS でも、 本格的に使いたいユーザは、 2.2 カーネルを使い続ける限り、 自分でこれらのパッチを実施する必要があります。 また、いくつものディストリビューションも、 これらのパッチを適用したカーネルを出荷しています。

そうしたことから、 linux-kernel の住人の方々は、落ち着きを失い始めました。 （2.2 カーネルで RAID と NFS を必要とする） 多くの方々にとっては、 動作するシステムを手に入れるためだけに これらのパッチが必要とされているのです。

それなら、 オフィシャルカーネルに統合する方法を見つければ いい、、、ですよね？

ところが、いくつかの問題があるようなのです。

• 2.2 カーネルのリリースが早すぎたこと。

  2.2 がどれだけ長い間待たれていたかを考えると、 もっと時間をかけるべきだった、なんて言うのは、 少し奇妙に聞こえるかもしれません。 けれども、ここで問題なのは、 2.2 が、 特定の機能 --- 例えば NFS サービス --- が本質的に動いていない状態で、リリースされてしまったことなのです。

• 2.1 シリーズの多くにおいて、NFS を誰も保守していなかったこと。

• Linux ユーザコミュニティが、 安定版カーネルの途中の、 混乱を招くような変更に対し、 ますます不寛容になっていること。

  安定版カーネルへのマイナーアップデートには、 (システムのその他の部分に対しては何もアップデートしなくても) 単純に動くことが期待されているのです。 現実の世界では、 しばしばカーネルのセキュリティ問題が現れ、 その修正が求められるはずであることを考慮すると、 この視点は無視できません。 Linux システムを業務に使用している方々は、 セキュリティホールを塞ぐだけのために、 混乱を招くようなアップデートを行いたくはないのです。

それでは、こうした状況の中でカーネルを進歩させるにはどうしたらいいでしょうか？

解決策は、 より少ない数の変更を含むメジャーリリースを頻繁に行うこと、 でしょう。 安定カーネルが、 リリース時点 (又はリリース直後) で真に「安定」しており、 新しいリリースが 2年も先の話というの「ではない」なら、 より大きな変更が統合されるのを、おとなしく待つことができますから。

2.3 のフィーチャーフリーズは当初一ヵ月も前のはずでしたが、 まだアナウンスされていません。 もし、 （RAID と NFS の実装が含まれる可能性がある） 2.4 のリリースが今年中に起るのなら、 このフリーズは、近いうちに行われる必要があります。 既に手遅れでなければの話ですが。

バウンスバッファ --- ビッグメモリと Raw I/O の競合を解消

「ビッグメモリパッチ」についての最初の LWN の報告は、 8 月 19 日の記事 (英語。 日本語) に遡ります。 このパッチは、 Intel ベースの Linux システムで 4 GB までのメモリをアクセス可能にするものです。 今週、このプロジェクトのスポンサーであるシーメンス社と SuSE は、 このパッチを発表する プレスリリース (英語) を出し、これが 2.3.15 に含まれることを示しました。

しかしながら、ビッグメモリパッチにはまだ不完全な点が一つ二つ残っています。 特に、 Stephen Tweedie 氏の、 同じく最近開発カーネルに追加されたばかりの、 raw I/O パッチを動かなくしてしまうのです。

Raw I/O パッチは、 ユーザ空間のバッファからデバイスへ、直接データを転送できるようにします。 カーネルのバッファキャッシュ経由のコピーをスキップするので、 いくつかの状況では明らかな性能アップが得られます。

ただ、まったくキャッシュを回避するということも、 また、同じように重要な点です。 他にアクセスする必要がないような、 ある種のデータでは、キャッシュは無駄なのです。 そのような、その場限りのデータをキャッシュすることは、 （キャッシュから）他のデータを追い出すという効果だけになってしまうので、 性能を向上するよりむしろ、システムの動きを遅くしてしまいます。 巨大なプログラムの make 後や、ファイルコピーを行った後で、ウィンドウシステムが応答するのに時間がかかるのを経験したことがある方は、このメカニズムが働くのを目にしているわけです。 キャッシュは、2つ以上のシステムでディスクを共用している際にも問題となることがあります。

では、なぜ、特に（ビッグメモリパッチと） raw I/O との間に問題があるのでしょうか？

一般的なデバイスの多くは、高位 (2GB を越える領域) のメモリにアクセスすることができないようです。 このようなデバイスに、高位のメモリとの間でデータを転送させようとすると、 良くても失敗、悪ければシステム異常の可能性があります。 カーネルは、低位のメモリにあるカーネル固有のバッファを 注意深く管理しているので、このような問題は健在化しません。 一方 raw I/O はユーザ空間のバッファを使用しているので、 何が起るか分かりません。 このため、ビッグメモリパッチは今のところ、 高位のメモリへの raw I/O を完全に禁止しています。

この場合の解決法は、「バウンスバッファ」になるようです。 バウンスバッファとは低位のメモリ中にあるカーネル空間のバッファです。 高位のメモリページへの I/O が要求され、かつデバイスがこれを扱えない場合、 バウンスバッファへの中間的なコピーが行われます。 このテクニックは raw I/O の「ゼロ・コピー」という点を台無しにしてしまいますが、 その他の利点はそのまま残ります。 バウンスバッファは、 それが本当に必要とされる時だけに使用されるように実装することも可能です。 適切に実装されたバウンスバッファにより、 raw I/O の問題を解決するだけでなく、 ページキャッシュを高位のメモリに置くこともできるようになるでしょう。

最後に、 いつか 4GB 以上のメモリがサポートされる日が訪れれば、 バウンスバッファの必要性はさらに高まります。 多くの PCI デバイスは 64-bit アドレッシングが出来ないので、 現状では高位のメモリにアクセス出来ているとしても、 その時には、このような助けが必要となるでしょう。

(Stephen Tweedie 氏に感謝します。 この記事は彼の linux-kernel へのメッセージを大胆に流用させていただいています。)

今週のその他のパッチとアップデート

• 性能測定カウンターパッチ version 0.6 (英語) が Mikael Pettersson 氏によりリリースされました。 このバージョンには AMD の Athlon プロセッサのサポートが含まれています。

• Devfs v120 (英語) が Richard Gooch 氏からリリースされました。

• Kallisto GPS カードのドライバ (英語) が David Skingsley 氏によりリリースされました。

関連 URL

LWN

カーネル（原文）

LinuxHQ

他のカーネル関連リソース（英語）

Kernel traffic

他のカーネル関連リソース（英語）