イベントレポート：第4回 The Linux Foundation Japan Symposium――Andrew Morton氏がLinuxカーネルの開発動向を報告
The Linux Foundation Japan Symposiumは、前回まで「OSDL Japan Linux Symposium」という名称で開催されていたイベント。今年1月のOSDL（Open Source Development Labs）とFSG（Free Standards Group）の合併および新組織The Linux Foundationの設立に伴って、今回からイベント名も変更されている。「第4回」というのは、第1回のOSDL Japan Linux Symposium（2006年6月13日開催）から通算して4回目という意味だ。
 | |
| The Linux FoundationエグゼクティブディレクターのJim Zemlin氏 |
まず最初に、The Linux Foundation日本担当ディレクターの工内隆氏とThe Linux FoundationエグゼクティブディレクターのJim Zemlin氏から開会の挨拶が行われた。Zemlin氏は、FSGでエグゼクティブディレクターを務めていた人物だ。氏はOSDLとFSGの統合について言及し、The Linux Foundationの役割について次のように説明した。
「Linuxは数十億ドル規模の市場を切り開き、メインストリームの企業向けOSとみなされるまでに成長した。この第一段階の成長に対しOSDLとFSGはそれぞれ大きな貢献をしてきたが、第一段階は終焉を迎えつつあり、われわれは第二段階へと足を踏み入れている。この第二段階の成長では『オープン』と『クローズ』というの2つのキーワードが重要になる。つまり、これまでと同様にオープンでありながら、これまで以上に“クローズ（緊密）な”連携が必要になる。Linuxに関わるすべての企業とコミュニティが一体となって、このプラットフォーム（Linux）を保護し、プロモーションを行い、標準化を進めていかなければならない。そして、そうした作業を中立的なかたちで集約的に行うために、The Linux Foundationが作られたのである」
Linuxカーネルの開発動向――Andrew Morton氏の講演
 | |
| Linuxカーネル2.6のメインテナー、Andrew Morton氏 |
開会の挨拶に続く最初の講演では、Linuxカーネル2.6のメインテナーであるAndrew Morton氏からカーネル開発の動向が報告された。ちなみにMorton氏は、昨年6月の第1回シンポジウムでも同様の講演を行っている。
今回の講演では、まず、昨年の講演で取り上げられた機能についてその後の開発状況が手短に報告されたあと、信頼性や拡張性、パフォーマンスといった要素に影響を与える、重要なサブシステムごとに詳細な説明が加えられた。以下は、Morton氏の講演資料に口頭で加えられた説明を付加したものである。
●Hardware virtualization（ハードウェアの仮想化）
- KVM（Kernel-based Virtual Machine）が登場し、速やかにカーネルにマージされた。KVMは仮想マシンが直接CPUにアクセスすることを可能にするデバイスドライバ。Intel VTやAMD-Vといった仮想化支援機能を備えたCPUで利用可能
- Core paravirtualization（擬似仮想化のためのコア機能、XenやVMwareが使用）がマージされ、現在は開発の最終段階に
- VMwareのVMI（ハイパーバイザーと仮想マシン間のインタフェース）がマージされ、2.6.22からサポートされる
- XenのdomUサポートもおそらく2.6.22で実現
●OS virtualization（OSレベルの仮想化）
- OSレベルの仮想化の目的は、1つのOSをパーティショニングして、個々のアプリケーションに専用の領域を割り当てられるようにすること
- 開発はゆっくりとだが、着実に進んでいる
- これまで行われた作業のほとんどは、カーネル内のグローバル・ネームスペース（utsname、PID、UID、shm IDなど）の仮想化対応
- ネームスペースの仮想化はnsproxyという構造体を介して行う
- 現在のコードはまだ動作しない。ユーザースペースで利用できる状態にするには、まだ多くの作業を行う必要がある
●Containerization（リソースのコンテナ化）
- OSレベルの仮想化に付随する機能。コンテナ化の目的は、コンピュータ・リソースを各パーティションに独立したかたちで割り当て可能にすること
- 主なコンテナ化の対象はCPU、メモリ、ネットワーク帯域
- Linux-VServerやCKRMなどいくつかの実装があるが、まだ全体的な計画がない状態（CKRMはほとんど開発がストップしている）
- Googleの開発者がcpusets（NUMAシステム向けのCPUリソース割り当て機構）の一般化を進めており有望である
- コンテナに対するメモリ制限機構は設計自体が白紙の状態
- Googleではネットワーク・クラスターをNUMAシステムに見せかける「fake NUMA」が使われており、このfake NUMAのノードをメモリ割り当ての単位として利用している。これはうまく動いているが、Linuxのコンテナ機構としてふさわしいものかどうかはわからない
- いずれにせよ、コンテナ化にはより多くの人材が必要
●Memory Management（メモリ管理）
- Mel Gorman氏のanti-fragmentationパッチを-mmパッチに統合。ただし、まだレビューが行われていない（anti-fragmentationはmemory hot-unplugの実現に役立つ可能性がある。また、コンテナのメモリ制限にも役立つかもしれないが実際のところは不明）
- マルチコアの大きなマシン、特にIntel CPUのマシンで、メモリ性能のスケーラビリティの問題が報告されている。おそらく、キャッシュラインのロックが原因となっているが、現時点では修正方針が固まっていない
- メモリ再要求（memory reclaim）の効率が（特に大きなデータベース・システムにおいて）悪いという報告が上がっている
●Filesystem（ファイルシステム）
- XFSは依然として最上級のスケーラビリティを持つファイルシステムだが、コードが複雑かつ巨大であるため、ディストリビューターがXFSをサポートしたがらない
- より広範囲なサポートと安定性を求めるベンダーは、（パフォーマンスを多少犠牲にすることになるとしても）ext4にフォーカスしていくものと思われる
- ext4のロードマップはしっかりしているが、実際の開発はあまり進んでいない
- ext4には人手が足りない状況だが、Red Hatのようなディストリビューターがビジネスプランにext4を組み入れれば、一気に開発が進むことになるだろう
- NFS4はさまざまな開発者からパッチが寄せられていて、着実に成長している（ただし、Morton氏自身はパッチの内容をあまりチェックしていないとのこと）
●AIO（非同期IO）
- 非同期IOは、ここ4年くらい進化していない。ファイルシステムの非同期IOはdirect-IOのみサポートという状況
- バッファド・ファイルシステムの非同期IOパッチが存在するがマージされることはないだろう（次のsysletsが提案されたため）
- sysletsは、すべてのシステムコールを非同期化するカーネル・サブシステム。今年中にマージされると思われる
- sysletsが採用された場合、既存の非同期IOコードは捨てられる
●kevent（イベント・デリバリー・フレームワーク）
- これまでのLinuxカーネルは統一されたイベント・デリバリー・フレームワークを備えておらず、パイプやtty、ソケット、非同期IO、シグナル、futexesなどは、それぞれ独自にイベント処理を行っている
- keventは、イベントの通知を1つのシステムコールで実現するために提案されたもの
- ただし、keventの進捗は芳しくなく、パッチの提供も少ない。もっと注目されるべきプロジェクトだが、人手が少ないためほとんど止まっている状態である
●その他の出来事
- utrace：ptraceを置き換えるプロセス・トレース・インフラ。Red HatのRoland McGrath氏が開発に当たっている。ptraceは、utraceの最上位レイヤーに配置される。現在のところバグ・レポートが出ていないのでうまく動くようだ。ただし、ptraceはアーキテクチャごとに実装が異なるため、utraceのマージは大変な作業になる。24くらいあるアーキテクチャのうち、4～5つはMcGrath氏が作業を行ったが、残りは手付かずの状態である
- 新しいpage replacementアルゴリズムに関する議論：1年くらいかけて慎重に作業すべき
- kprobe（カーネル・トレース・インフラ）：2.6.22でマージされる予定
- Real Time Kernel：Ingo Molnar氏が中心となって進めているReal Time Kernelの機能は、メイン・ツリーのカーネルにふさわしくないもの（スレッドの同期実行など）いくつかあるものの、最終的にはメイン・ツリーにマージされる予定（時期は未定）
カーネル開発プロセスにおける問題点
カーネルの各機能に関する報告のあと、Morton氏は話題をカーネルの開発プロセスに移した。Morton氏によると、1つのパッチをマージする作業は、「2週間かけてパッチをマージし、その後2カ月間で安定化を図る」という、2.5カ月のサイクルで行われているという。「ここ数年、このやり方で作業をしているが、うまく機能している。（パッチを提供する）ベンダーもこのサイクルにおおむね満足しているようだ」（Morton氏）。
ただし、カーネル開発プロセスにまったく問題がないわけではない。Morton氏は、カーネル開発チームが抱えている弱点として、パッチをマージしたあとの回帰テストが十分に行われていないことを挙げ、次のように述べた。「先日リリースした2.6.20.1には（2.6.20に対する）約110個のパッチが含まれていた。それだけたくさんのバグが残っている状態で2.6.20をリリースしてしまったということだ」。
こうした問題を改善していくためには、バグ修正のみの期間を設けてその間の機能追加を凍結する必要があるかもしれないとMorton氏。また、氏はバグの混入を減らすために、別の開発プロセスの変更も提案しているという。その提案とは、第3者のレビューを受けていることをパッチの受付条件とすること。開発者間のパッチの相互レビューを促進しようという意図によるものだ。もっとも、この提案に関しては、Morton氏自身も実現が難しいと見ている。「レビューを義務付けると開発の進捗がスローダウンすることになるので、大多数の開発者には受け入れがたいだろう」（Morton氏）。
プレゼンテーション終了後、いくつかの質問が聴講者から発せられたが、ここではRSDLスケジューラについての質問を取り上げておこう。RSDLスケジューラは、Con Kolivas氏が開発している新しいCPUスケジューラだ。Morton氏によると、開発が順調に進めば、RSDLスケジューラのマージは2.6.23あたりになるだろうとのことだ。「もちろん、その前に十分なテストを行う必要がある。負荷の高い大規模データベース・サーバでのテストが必要だろう。3～5％程度のパフォーマンス低下が発生するようなので、その問題に対処してからカーネルにマージすることになる」とMorton氏。
なお、質問者の「RSDLスケジューラに興味があるので、できればテストに参加したいと思います」という言葉を受け、Morton氏はテスト後のレポートについて次のように述べた。
「テスト段階にあるパッチについて、バグ・レポートはよく届くが、うまく動いたというレポートはほとんど届かない。そのため、こちらとしては『誰も何も言ってこないのだから、うまく機能しているのだろう』と想像するしかない。誰もテストしていないのか、それとも問題がないのか判断できないわけだ。そこで、テストをしたら、問題なく動いた場合もぜひフィードバックをしてほしい」
The Linux Foundation Japan
http://www.linux-foundation.jp/
