6月版　新機能のバトルフィールド「linux-staging」登場

小崎資広
2008/6/30

linux-kernelメーリングリスト（以下LKML）かいわいで起きるイベントを毎月お伝えする、Linux Kernel Watch。2008年5～6月のLinuxカーネルメーリングリストでどんなことが起きたのか見てみましょう。

編集部注：これまでKernel Watchを執筆してきた上川氏の都合により、今回より筆者が小崎資広氏に交代しました

新ツリー「linux-staging」発進！

　6月11日、Greg K-Hが新しい開発ツリー「linux-staging」を作成したことをアナウンスしました。これは主に、新しいドライバやファイルシステムを開発初期段階で集約しておく目的のものです。これにより、開発者は新しい機能を簡単にテストできるようになり、品質改善が加速されることを狙っています。

　気になるのは、既存のlinux-nextや-mmツリーとの違いです。linux-stagingは、次回のマージウィンドウではマージ候補対象外であるような、開発初期段階のコードを対象にしています。かつ対象となるのは新機能だけで、既存のコードの修正は含みません。

　linux-nextは、-mmのマージ候補のための、パッチコンフリクトチェック用デイリービルド環境といえるでしょう。一方-mmは、近日中に-rcツリーにマージ予定の機能のテストベッドとして使われることが想定されています。つまり、順番としてはlinux-staging → linux-next → -mm → -rc → releaseという順番でパッチが流れていくことが期待されています。

　Gregは併せて、ビルドエラーの早期発見を狙って、linux-stagingをlinux-nextのビルド環境に含めることも提案しました。これに対し、Theodore Tsoから「linux-nextの位置付けからしておかしくない？」と物言いが付きましたが、みんな、幅広くドライバの面倒を見ているGregの激務ぶりを知っているため、結局、Gregの提案どおりに運用することになったようです（しかし数日後には、Linux-stagingのパッチが原因でLinux-nextがビルドできなくなった、と早速苦情が飛んでいました）。

　また6月22日には、初の公開アナウンスとなる、2.6.26-rc7用のlinux-stagingツリーが紹介されました。現在のところ、15のドライバと1つのファイルシステム（Novell FSなんて筆者は初めて聞きました）が含まれています。

　現時点ではGreg K-Hが抱えていたものをツリーに落としただけなので、linux-stagingはまだまだ増える見込みです。ですが、現時点でさえ193ファイル、13万行以上の変更に上っています。これをいままで1人でやり繰りしていたGregはやはりすごいな、と思いました。

MMに激震、Lockless pagecacheがとうとうマージ

　Nick Pigginが数年前から取り組んでいた「Lockless pagecache」パッチが、とうとう-mmにマージされました（2.6.26-rc5-mm1でマージされたので、早ければ2.6.27での新機能となる見込みです）。

　従来、DBのような非常に大きなファイルに対し、複数のCPUがそれぞれファイルアクセスを行うような場合、1つのボトルネックがありました。I/Oシステムコール中のファイルオフセットから、対応するページキャッシュをルックアップする処理です。このルックアップでは、処理の都合上、1つのファイルにつき1つのロックを掛けることになります。従って、全CPUが同じファイルにアクセスする場合は、どうしてもロック競合が発生してしまっていたのです。

　Lockless pagecacheでは発想を逆転させて、ロックが不要になるようアルゴリズムを見直すことで、大幅な性能向上を図ることができました。

　Nickが示したデータによると、前述のルックアップを行う関数「find_get_page()関数」の性能は、シングルスレッドの場合で2倍から3倍になっています。

find_get_page takes: (cycles)

               ppc970 (g5)  K10  P4 Nocona  Core2

  vanilla           275                   85   315                 143

  lockless         125                   40     127                 61

find_get_page()関数の性能比較データ（単位はCPUサイクル）

　また、ロックレスになるのでマルチCPUにおいてもきれいにスケールし、64CPU環境においては、従来の250倍の性能向上が観測されているとのことです。

　ただ、実装がかなりトリッキーなので今後の保守が心配（注1）ですが、この性能向上にはそれだけの価値があるといえます。

注1：この話には後日談があり、同時期にマージされたSplit LRUシリーズ（*注2）とパッチがコンフリクトし、早速大量のレグレッションが発生してしまいました。筆者も開発に参加しているので、できるだけ早く安定させるようにしたいと思っていますが、7月に来日するAndrew Mortonに何を言われるかと、いまから胃が痛いです。

注2：「Linuxメモリ管理の最先端を探る」を参照してください。

関連記事：
	番外編　Linuxメモリ管理の最先端を探る http://www.atmarkit.co.jp/flinux/rensai/watch2008/watchmema.html

ext3より遅い？　ext4のパフォーマンス

　最近ようやく開発が落ち着いてきた新ファイルシステム「ext4」ですが、Holger Kiehlが、これについて興味深いメールを投稿しました。彼の測定によると、2年前はext4がext3よりも高速だったが、現在はそれが逆転しており、ext4の方が低速だというのです。

　彼の提示したベンチマークツール「bonnie++」の結果を見ると、確かにext3は性能が改善しているにもかかわらず、ext4は逆に、劣化してしまっています。

  Version 1.03           ------Sequential Output------ --Sequential Input- --Random-

                                         -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--

  Machine           Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP

  ext3(2 years ago) 16G  38621  98 194816 94 87776  49 37921 92 239128  54 1402 5

                  16G  47000  99 194276 94 89232  49 38628 92 240539  55 1399 5

                    16G  45873  98 178195 90 89726  50 38482 92 240490  55 1381 4


 
ext3 (now)        16G  51501  97 210601 91 100479 32 55528 98 301589  44 1198 5

                    16G  52702  98 215540 94 99339  32 55376 97 300933  44 1159 4

                    16G  52426  99 212584 94 99091  31 55656 98 301669  44 1160 4


 
ext4(2 years ago) 16G  59223  91 264155 45 111459 36 57313 99 317944  63 1478 7

                    16G  58814  92 276803 47 110418 36 57105 99 317534  65 1525 5

                    16G  58299  92 274523 48 110290 36 56723 99 318839  65 1502 4


 
ext4 (now)        16G  52965  98 224199 89 108440 32 56389 99 303792  42 1526 4

                    16G  52792  98 223980 92 107685 32 56350 98 303066  42 1532 4

                    16G  52994  98 222354 92 107802 32 56386 99 303727  41 1455 4

bonnie++の結果。K/secは大きいほど高速、%CPはCPU使用率なので低いほど良い

　このメールは多くの開発者の関心を呼び、原因をめぐって、非常に多くのレスポンスが付きました。いわく

mballoc（注3）がCPU使用率を上げてしまっているのではないか、なぜなら、現在のext4は、メモリ上でエクステントマップを構築する仕組みが結構重いので、キャッシュが全然乗っていない状況でベンチマークを測ると、それが見えてしまうのではないか
最近取り込まれたバリアーのサポート（注4）が原因ではないか
現在mainlineにマージされているdelalloc（注5）はバグのせいで遅い。ext4 patch queueでは解決しているのではないか

といった推測が提示され、メインラインにマージされていないpatch queueを用いて再テストすることになりました。

　ところが、patch queueの最新バージョンでは、速度は良い成績を示すものの非常に不安定で、パニックやハングが次々発生したと苦言が呈されました。どうやら、ext4が常用可能になるにはまだまだ時間がかかりそうです。

  Version 1.03     ------Sequential Output------ --Sequential Input- --Random-

                   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--

  Machine          Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP

  ext4(patchqueue) 16G  59727 98  252733 52 110177 25 55821 98 296739 42  1553 5

                   16G  61047 99  239242 48 111664 25 55706 98 297151 42  1545 4

                   16G  60503 99  241532 47 109655 25 55671 98 297648 42  1552 3

再テストの結果

注3：Multiblock Allocationの略で、Alex Tomasを中心に開発されました。複数のブロックをまとめてアロケートすることにより、速度向上とフラグメント防止を図る仕組みです。

注4：SCSIのようにデータ転送の順序入れ替えを許しているプロトコル上にファイルシステムを構築する場合、ジャーナル書き込みとコミットが逆順になってしまうと、データ不整合が発生してしまいます。それを防ぐのがバリアーという仕組みです。

注5：Delayed Allocationの略。同じくAlex Tomasを中心に開発されました。ディスクブロックのアロケーションを可能な限り遅延させることで、フラグメント防止を図る仕組みです。

コンパイラの最適化がカーネルをパニックさせるとき

　Arjan van de Venは、kerneloops.org（注6）のチャートを赤丸急上昇中の、新しいOopsがあると報告しました。

　これは最初は、コールスタックからext3のバグだと思われていたのですが、実はgccのバグだということが分かりました。最適化の一環で、short変数の配列のアクセスに16bit loadではなく32bit loadを使うよう変更されてしまっていた個所があったのですが、それが原因となり、配列がちょうどページ境界にあるときにページ境界を超えたアクセスが発生すると不正アクセスとなり、落ちていたのです。

　幸い、このバグが発生するのはgcc4.3.1のみであり、このバージョンを採用しているのはFedora 10の開発中ツリーぐらいで、かつgccのデベロッパにも状況は通知されているとのことです。どうやらこの件は丸く収まりそうな感じです。

　ちなみに、こういう厄介なバグが大好物のLinusが予想どおり飛び付いていましたが、再現環境構築中にあっさり解決されてしまい、「うわー、メール全部読んでから作業するんだった」と落ち込んでいました。

注6：http://www.kerneloops.org/。カーネルのパニックログを収集してパニック個所のランキングを集計してくれるサイトです。もちろん、上位にあるものはみんなが困っているバグなので、至急直すべき、ということになります。

5月版へ

1/2

Index
Linux Kernel Watch　6月版　新機能のバトルフィールド「linux-staging」登場

	Page 1 　新ツリー「linux-staging」発進！　MMに激震、Lockless pagecacheがとうとうマージ　ext3より遅い？　ext4のパフォーマンス　コンパイラの最適化がカーネルをパニックさせるとき
	Page 2 　rootkitかと思ったら…… 　「ドライバを開放せよ」、138人の開発者が声明　-stableの進ちょく

連載 Linux Kernel Watch

　Linux Squareフォーラム Linuxカーネル関連記事

	連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
	連載：Linuxファイルシステム技術解説ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
	特集：全貌を現したLinuxカーネル2.6［第1章］エンタープライズ向けに刷新されたカーネル・コアついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
	特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
	特集：仮想OS「User Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	Linuxのカーネルメンテナは柔軟なシステムカーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った
	more

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

Linux ＆ OSS フォーラム新着記事

【 pidof 】コマンド――コマンド名からプロセスIDを探す （2017/7/27）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、コマンド名からプロセスIDを探す「pidof」コマンドです。
Linuxの「ジョブコントロール」をマスターしよう （2017/7/21）
　今回は、コマンドライン環境でのジョブコントロールを試してみましょう。X環境を持たないサーバ管理やリモート接続時に役立つ操作です
【 pidstat 】コマンド――プロセスのリソース使用量を表示する （2017/7/21）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、プロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。
【 iostat 】コマンド――I/Oデバイスの使用状況を表示する （2017/7/20）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、I/Oデバイスの使用状況を表示する「iostat」コマンドです。