10月版 2.6.27はLTSに、命名規則の変更案も飛び出した


小崎資広
2008/11/4

 2008年に入ってからずっと手掛けていたSplit LRUパッチ(参考:「Linuxメモリ管理の最先端を探る」)がやっと2.6.28のマージウィンドウにてマージされ、ほっと一息ついてる筆者です。さてさて、10月はカーネル2.6.27がリリースされたので、そちらの紹介をメインにお届けします。それではどうぞ!

Linux 2.6.27にマージされた主な機能

 2.6.26から約3カ月、10月10日にリリースされたLinux 2.6.27の主な機能や修正点から紹介していきましょう。

■ext4:Delayed Allocation

 この機能は、そのまま「遅延アロケーション」ともいいます。従来のext3では、write()システムコールにおいてキャッシュに書き込みを行った時点で、ディスク上のブロックも予約していました。これには、キャッシュをディスクに反映するときに、ディスクがいっぱいで書き込みができないという状況を防ぐ意味があったのですが、以下の2つのデメリットがありました。

  • UNIXシステムにおいてテンポラリファイルの作成は極めて一般的であり、そのようなすぐ消されてしまうファイルでは、まったくディスクI/Oが発生しない。このような状況では、ブロックの予約処理は負荷を上げるだけで何の意味もない。

  • アプリケーションはサイズの大きなファイルを書き込むとき、しばしば、数MB程度の複数のwrite()に分割して書き込みを行う。このような場合、write()時にすぐさまディスクブロック位置を決めてしまうと、後続のwrite()で渡されるデータと連続する位置を確保することは難しく、フラグメントが進みやすくなってしまう。

 これに対し、XFSreiser4btrfsのようなファイルシステムでは、キャッシュ書き込み時はディスクの空き容量だけを減少させ、ディスク上のブロック位置は実際のディスクI/O発生時に決めるというアイデアを用いてこの問題を克服しています。これが「Delayed Allocation」です。

 特に、エクステントベースのファイルシステムでは、フラグメント解消がメタデータの領域削減にも直結するので、ほぼ必須の機能といってもいいでしょう。このパッチによって、ほとんどのワークロードにおいて性能改善が見られることが報告されています。

 もっとも、このパッチを導入してもなおext3に性能で負けるという報告も出ているところが、ext4の前途多難さを物語っているのですが……。

■ブロック・レイヤにおけるデータの完全性チェック

 btrfsやext4には、チェックサムを用いたデータ完全性チェックが実装されています。これは、データ読み出し時にデータとCRCを比較することで、ハード障害による破損データの読み出しを回避するために使われています。

 しかし実際には、ディスクに書き込む瞬間にすでにデータが壊れていることの方が多いのです。このため、上記の方法だけでは完全ではありません。

 そこで、SCSIにおいて現在使われていない、1セクタ当たり8バイトの空き領域(つまりSCSIにおいては、1セクタは512バイトではなく520バイトということです。過去に特定ベンダのRAIDコントローラが使っていたらしいのですが、いまは積極的に使われていないのだとか)を用いて、end-to-endでCRCチェックを行い、書き込み途中にデータが化けてしまったときに補足しようというパッチです。

 このパッチはFSチェックサムと競合するものではなく、補完関係にあるものと位置付けられています。

■ネットワークデバイスのマルチキュー対応

 最近のネットワークチップ、特にワイヤレスネットワーク系のチップは、複数の送信キュー(Multiqueue)を持つものが一般的です。これにより通信をサービスごとに分類し、動画・音声などのマルチメディア系のデータを優先的に送信することにより、音飛びなどを防いでいます。

 ところが、従来はカーネル本体が複数送信キューをサポートしていなかったため、ドライバ側で独自にフレームワーク的なコードを実装する必要があり、大変でした。それが改善されたことになります。

 日本の携帯電話の場合、音声通話までLinuxで制御している例は少ないので、直接恩恵を受ける人は少ないかもしれません。とはいえ、ネットワーク・ドライバ・フレームワークが変更になるので影響範囲は非常に大きく、rcフェイズで全くregression(リグレッション)騒ぎを起こさなかったDavid Millerは尊敬に値します。

■ftrace

 ftraceは、SystemTapなどとは異なり、完全にカーネルに閉じた新しいトレーサーです。従来、カーネルの性能分析にはOprofileなどが使われていましたが、Oprofileはロックの取り方に難がありました。プロセスが必要以上に寝過ぎていたり、割り込み禁止区間が長過ぎて応答性能が落ちてしまっているなど、「CPUは動いていないけれども問題はある」という状況をうまく扱えませんでした。

 これに対しftraceは、割り込みやスケジューラにフックを入れることで、レイテンシ・トレースの直接的なサポートを実現しています。またgccの-pgオプションを使って全関数の呼び出し履歴を追跡できる、強力なトレーサーになっています。

 余談ですが、この-pgオプションによる全関数トレースの処理は非常に重たいです。そこで、ftraceの主要機能の1つとして、事前に全関数の先頭に5バイトのNOPを挿入しておき、関数トレースモードをONにしたときのみ、プロファイラ関数呼び出しが動的パッチングにより生成されるという機能がありました(x86においてはjmp命令が5バイトです。ですから「5バイトNOP」というのは、カーネルでしばしば議論の鍵となるマジック・ワードです)。

 しかしこの機能には、インテルのオンボードNIC用ドライバであるe1000eで、EEPROMを上書きしてしまい、二度と使えなくしてしまう問題(バグ)があることが分かり、問題回避のため、2.6.27.1でいきなり無効化されてしまいました。2.6.28で再び有効化される見込みです。

 被害に遭われた方には非常に申し訳ないのですが、このバグは機構としては非常に興味深いもので、以下のようなシーケンスで発生します。

  1. あるモジュールがロードされ、そのモジュールの__init関数が呼び出される
  2. ここで-pgで生成されたmcount()呼び出しの延長で、ftraceがアドレスを記録し、後からパッチできるようにする
  3. モジュールが初期化完了時に__init関数を解放する(初期化が終わったら初期化関数は二度と呼ばれないため)
  4. しかしftraceはこの解放をキャッチしない(できない)
  5. e1000eドライバがEEPROMをメモリにマップする。32bitマシンではアドレス空間の空きは非常に貴重なので、3で空けた場所と割り当てが重複する確率は高い
  6. ftraceがNOPパッチング。でもそこは、目標の関数先頭でも普通のメモリ領域でもなくて、e1000eのI/Oマップドエリア……
  7. ちゅどーん!

 まさに自己書き換えコードならぬ「事故書き換えコード」ですね。このバグでは、bisectするたびにカードがお亡くなりになっていくので、原因追究がとても大変だったそうです。南無。

 なお個人的には、この動的パッチング機構がないと関数トレースは重過ぎてまったく実用にならないので、この機能が再度ONになってからが本領発揮かな……と思っています。

■外部ファームウェアローディング

 いくつかの機器(主にネットワークカードとストレージカード)には、汎用的なCPUとメモリが載っており、実行時にファームウェアをロードして実行する仕組みになっています。

 しかしながら従来のカーネルには、ファームウェアをユーザー空間からロードする仕組みがありませんでした。このため、プロプライエタリなファームウェアが静的にカーネルにリンクされるという、ライセンス的に問題のある状況になっていました。

 この修正では、ドライバがrequest_firmware()を呼び出すと/lib/firmwareにあるファームウェアが動的に読み込まれることになり、ライセンス問題が解決します。要するに、もうdebianは無線LANサポートでUbuntuに負けませんってことです(まとめ過ぎ?)

 もっとも、ファームウェアアップデート時の互換性の配慮についての議論はまだ練れていない感じです。このあたりはディストリビューターを交えて運用経験を積むことにより、さらに仕組みが拡張されていくかもしれません。

関連記事:
リンク 2008年7月版 ファームウェアの置き場所を巡ってフレームウォー
http://www.atmarkit.co.jp/flinux/rensai/watch2008/watch07a.html

■1GB ヒュージページサポート

 x86_64限定ですが、従来の2MBサイズのヒュージページ(hugepage)に加えて、1GBサイズのヒュージページがサポートされました。

 hugetlbfsのマウントオプションにて、どちらのサイズを選ぶか指定する方式なので、複数のサイズを混在させることもできます。ただし、共有メモリ経由でヒュージページを使う場合はサイズを指定する方法がなく、1GBページは使えないので注意が必要です。

■x86の最大CPU数、最大ノード数が拡大

 最大CPU数が4096、最大ノード数が512まで拡大されました。当面はSGIのx86_64スパコンくらいでしか意味がなさそうですが、カーネルデベロッパーから見ると、事実上、cpumask_t変数をスタックに置くことが全面禁止になってしまったことを意味します(スタックが4Kbytesしかないのに、1変数あたり512bytesの変数を置くなんて……)

 ほかに、すでに紹介済みの機能としては以下のものがあります。

- Lockless page cache
2008年6月版「新機能のバトルフィールド「linux-staging」登場」参照)
- close-exec拡張パッチ
2008年8月版「ブート時間の短縮にかけるカーネルアスリートたち」参照)

9月版へ
1/2

Index
Linux Kernel Watch 10月版
 2.6.27はLTSに、命名規則の変更案も飛び出した
Page 1
 Linux 2.6.27にマージされた主な機能
  Page 2
 2.6.27は2.6.16に代わるLTSに
 Ingo、またまたお説教を食らうの巻
 サブシステムに進化するlinux-staging
 バージョン名規則が変わる? 「自転車置き場議論の始まりだ!」
 -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関連記事を紹介します


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

注目のテーマ

Linux & OSS 記事ランキング

本日 月間