11月版　怒りのLinus――メンテナにかんしゃく玉爆発

小崎資広
2009/12/10

　お久しぶりです。10月はKernel Summit、Japan Linux Symposium、OSS貢献者賞受賞講演と欠席不可のイベントが連続で並んでいたところに、Summitの参加者から悪性の風邪をうつされて、本気で死にそうでした。というか本当に倒れました。

　おかげで11月は、たまった仕事の挽回（ばんかい）が大変で大変で……。もうKernel Summitから1カ月もたったなんて信じられませんが、気を取り直して今月もいってみましょう。それでは、どうぞ。

スケジューラ改善、その後

　前回大騒ぎになったスケジューラ・レイテンシですが、Kernel Summit（注1）でその後の進ちょくが報告されたので後日談をば。

　その後もスケジューラ開発者の改善活動により、レイテンシはどんどん改善されていったわけですが、難しい問題があることが分かってきました。

　PostgreSQLやいくつかのプロプライエタリDBMSは、排他制御にpthread_mutexを使わず、独自にユーザー空間のspinlockを実装して使っています。そして、ある種のレイテンシ改善コードはコンテキストスイッチの頻度を増やす結果になるので、スピンロックを保持しているスレッドがコンテキストスイッチで処理を奪われてしまう機会が増えます。

　スピンロックを保持したスレッドがCPU待ち状態になると、このスレッドが再度スケジューリングされるまで、スピンロックが解放されません。このため、スピンロック待ちの頻度が高くなり、OLTP性能が劣化してしまいます。さらに、スピンロックの解放を待つ側のスレッドは、ロックの解放をビジーループで待つため、CPU時間を多く使用します。このことが、スピンロックを保持したスレッドの再スケジュールを遅らせるといった間抜けな事態を生んでしまうのです。

　もちろんユーザーランドでスピンロックを使うのは、本質的に筋が悪いアイデアなのですが、LKML文化は、Linusの「カーネル開発者がユーザーランドを議論しても愚痴にしかならない。愚痴るヒマがあったら手を動かせ」という意向により、ユーザーランドがおかしいとしか思えないときでも放置厳禁、そのようなレイテンシ改善コードはdisableされていきます（注2）。

　この問題はサミットの席上でも議論になり、「DB側がおかしい」論が何人かから出ましたが、Chris Mason（だった気がする……ちょっと自信がありません）が、そう簡単ではないと説明しました。彼が以前かかわったプロジェクトの経験では、現在のglibcのlock実装では、pthread mutexに変更してしまうと性能が落ちてしまうのだそうです。

　これについてはスケジューラ関係者から、「いまのglibc実装がfutexの実力を出し切っていないのはknown problemなんだけど、glibcはいつものようにグズグズしているんだ（注3）」との解説がありました。

　結局、「glibc側の解決なんかを待っていてもどうにもならないから、LKMLでliblockを開発するべきだろう。われわれが一番futexを理解しているのだし」という意見で皆の合意が取れ、ちょうど時間も来たのでお開きとなりました。具体的にfutexのどの機能のことを指しているのかいまいち把握できませんでしたが、議論が前向きなのは、聞いていて気持ちいいですね。

　ちなみにLinusは、この問題をいまいち理解できないらしく、「レイテンシ改善でスケジューラ？ おいおい、普通デスクトップでのレイテンシってのはI/Oスケジューラとかその辺がネックになるわけで、スケジューラが問題になったりしないよ」とかいってましたが、その発言は全員にスルーされてました（ホント、Linusには容赦ないよな）。

　なおこの話には、さらに後日談があります。今回のサミットにはエンドユーザー枠で非カーネル開発者が何人か招待されており、その中の1人に、PostgreSQLの開発者がいました。そのエンドユーザーセッションでは「え？ Linux独自機構？ そんなの意味ないよ。PostgreSQLはコミッタが対応アーキテクチャより少ないぐらいで、開発力不足に苦しんでいて、開発はどうしても保守的になる。Linuxスペシャルな対応なんてしないと思うよ」と話し始めて、ちゃぶ台返し、星一徹状態。何人かの開発者は苦笑していました。

関連記事：
	2009年9月版　帰ってきたCon Kolivas、大論争を呼ぶの巻
	全貌を現したLinuxカーネル2.6［第1章］

注1：Kernel SummitはLinusをはじめとした世界の主要なLinux開発者が集まり、カーネルの現状の課題や今後の方向性について話し合う会議です。毎年開催場所を移しながら開催されており、第9回の今年は東京で開催されました。出席者は招待者のみとなっており、招待者はLinuxへの貢献度および主要な議題に関連するトピックを持っているかどうかなどを勘案して選定されています。Summitに招待されるのはカーネル開発者の間でとても名誉なことだと思われており、Summit参加者の発言はLKMLでも一目置かれます。 注2：つまり、特殊なオプションを設定しない限り、改善前とまったく同じ動作をするということです。 注3：もちろんglibcが間抜けだからそうなっているのではなく、古いkernel＋新しいglibcの組み合わせでの動作を壊してしまうことを嫌う文化なので、既存のコードに影響のある変更は特に慎重なのです。

ext4ファイルシステム破損問題が解決、犯人は……

　10月中LKMLを賑わせ続けた「ext4ファイルシステム破損バグ」がようやく修正されました。

　これは、毎週のように新しい被害者が出るほどの高頻度破損で、最初は「本当にバグなのか？」とか「Karmic（Ubuntu 9.10）でばかり起きているようだけど、Ubuntu固有の問題？」などと真贋（しんがん）不明なうわさが錯綜（さくそう）。Tedも苦し紛れに、「今回のマージウィンドウではオレがLinusに送ったパッチ以外に、Jan Karaから直接送られたパッチも入っている、その辺りの整合性を疑っている」などと、責任の押し付け合いを始める始末。Kernel Summitでも、ちょうど新たな被害者が出ていたこともあってホットな話題になり、宴会中何度も耳にしました。

　傑作だったのは、本人が知らないうちにうわさに尾ひれが付いて犯人にさせられていたHidehiro KAWAIです。「おれはHITACHIの人から直接聞いたぜ」「なに、そうか！ じゃあ今度ヤツをDisりまくっておくぜ、HAHAHA！」などと、酒の席ということもあり、断定口調で結構ヒドイ会話をしていたのですが、真犯人は違いました。

　ext4にはジャーナルチェックサムという機能があり、ジャーナルログにチェックサムを付加することができます。これにより、ハード障害やカーネルバグによってトランザクションログ破損が発生した状況では、fsckが不正トランザクションデータをロールフォワードしてしまうことによりファイルシステムを破壊してしまう状況を防ぐことができます。

　このチェックサム機能、従来はオプション機能だったのですが、今回のマージウィンドウでオプション扱いではなくなり、デフォルトでenableに変更されました。ところが、ジャーナルログが一周した場合の考慮が抜けている個所があり、ジャーナルが一周したところでリブートすると、チェックサムエラーが発生し、おかしなことになっていました。

　結局、このオプション変更commitがLinus自身の手によりrevert（バグなどの判明により、あるパッチの変更を元に戻すこと）され、問題は解決。Linusは2.6.32-rc6のリリースノートで、「ext4のバグがrc6のリリース遅延の一因だった」と書いたうえで、Ericおよびほかの障害切り分け協力者たちに特に感謝をしたいと、ねぎらいの言葉を述べました。Linusは「だって、ファイルシステム破損はほかのどんなバグよりも僕をナーバスにさせるからね」とメールを締めくくりました。

　コード行数的には変更は落ち着いてきているものの、マージ判断が甘くてなかなか安定しないext4。業務運用に耐える品質になるには、まだしばらくかかりそうです。

関連記事：
	2008年2月版　OOM killerとの危険な関係に終止符は打てるか
	JFSのファイル管理とジャーナリングの実装

9月版へ

1/2

Index Linux Kernel Watch　11月版 　怒りのLinus――メンテナにかんしゃく玉爆発

Page 1 　スケジューラ改善、その後 　ext4ファイルシステム破損問題が解決、犯人は…… 　 Page 2 　怒りのLinus――Linuxコミュニティにおけるメンテナの役割とは 　お帰り！ ゼロページ

連載 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

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）