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カーネルの開発体制などについて伺った

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

@IT Special

- PR -

TechTargetジャパン

Linux & OSS フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Linux & OSS 記事ランキング

本日 月間
ソリューションFLASH