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()で渡されるデータと連続する位置を確保することは難しく、フラグメントが進みやすくなってしまう。
これに対し、XFSやreiser4やbtrfsのようなファイルシステムでは、キャッシュ書き込み時はディスクの空き容量だけを減少させ、ディスク上のブロック位置は実際のディスク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で再び有効化される見込みです。
被害に遭われた方には非常に申し訳ないのですが、このバグは機構としては非常に興味深いもので、以下のようなシーケンスで発生します。
- あるモジュールがロードされ、そのモジュールの__init関数が呼び出される
- ここで-pgで生成されたmcount()呼び出しの延長で、ftraceがアドレスを記録し、後からパッチできるようにする
- モジュールが初期化完了時に__init関数を解放する（初期化が終わったら初期化関数は二度と呼ばれないため）
- しかしftraceはこの解放をキャッチしない（できない）
- e1000eドライバがEEPROMをメモリにマップする。32bitマシンではアドレス空間の空きは非常に貴重なので、3で空けた場所と割り当てが重複する確率は高い
- ftraceがNOPパッチング。でもそこは、目標の関数先頭でも普通のメモリ領域でもなくて、e1000eのI/Oマップドエリア……
- ちゅどーん！
まさに自己書き換えコードならぬ「事故書き換えコード」ですね。このバグでは、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 |
 |
|
||||
|
||||
 |
連載 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カーネルの開発体制などについて伺った |
|
- 【 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」コマンドです。
 |
|
|
|
|
