4月版 RCUの全面書き直しも！ 2.6.29は何が変わった？
小崎資広
2009/5/8
いやあ、文字数の都合で書けませんでしたが、4月最終週はIngoがいい出した「カーネル専用コンパイラを作ろうぜ！」スレッドが大盛り上がり。おバカな話題ほどスレッドが伸びるのは、全世界共通ですね。
それでは予告どおり、今回はカーネル2.6.29についてのよもやま話をお送りいたします。どうぞ。
カーネル2.6.29の主な変更点
■ランダムシード受け渡し方法の変更によるアプリケーション起動の高速化
最近のgccには、glibcと連携してスタック破壊を検知するSSP（Stack Smashing Protector）という機構が実装されています（-fstack-protectorオプション）。これはスタックに「カナリア値」と呼ばれる特殊な値を埋め込み、関数リターン時に、その値が無変更であることを確認することで実現されています。
このカナリア値ですが、攻撃者が事前に値を予想できてしまうと簡単に回避できてしまうため、適切なランダム値を使う必要があります。
従来glibcは、このためにmain()が始まる前に毎回/dev/urandomをオープンしていました。しかし、特にシェルスクリプトのような小さなプロセスを大量に生成する処理において性能劣化が大きく、問題になっていました。
Kees Cook（注1）は、「glibcは最初にTSC時刻を取得してるんだから、代わりにそれを加工したものをシードに使おう」と提案しましたが、「ハック過ぎる（＝本質的ではないアプローチ）だろう」とUlrich Drepperに拒否されます（注2）。それを受けてJakub Jelinekは「正しい解決策は最初からカーネルがランダムシードを渡してくれることじゃないのか」と提案します。
あまり知られていないことですが、Linuxはexecシステムコール実行時に、引数・環境変数のほかに「補助ベクタ」といわれるlibc用の隠し引数をスタックに渡しています。ここを拡張することできれいに実装できるだろうというのです。この提案はめでたく受け入れられ、マージされました。
| 注1：カノニカルの人がパッチ出すなんて珍しい 注2：筆者も、予測不可能性を甘く考え過ぎだろうと感じました |
■RCUが全面書き直しで「Tree RCU」に
組み込みからスパコンまでサポートするLinuxの驚異的なスケーラビリティを支える構成要素の1つに、RCU（Read-Copy Update）があります。このRCUが全面的に書き直されました。
| 関連記事： | |
 |
全貌を現したLinuxカーネル2.6［第1章］（＠IT Linux Square） |
作者のPaul McKenneyいわく、「従来のRCUのスケーラビリティの限界は、たかだか数百CPUだった。この長年の性能バグ問題を直す必要がある（注3）。だから4096CPUまでスケールする形で再実装した」ということらしいです。
| 注3：バグ……かぁ？ |
まずRCUのおさらいから。
RCUにおいては、read-sideは一切ロックを取る必要がありませんが、クリティカルセクション内でコンテキストスイッチが起こらないことを保証しなければなりません。対するreclaim-sideでは、スケジュール処理の中でRCUにコールバックし、全CPUが1回以上スケジュールされたことを確認してから、call_rcuで登録された破棄処理を開始します。これによりread-sideがクリティカルセクションを抜けていることを保証します。
さて、ここで問題になるのは「全CPUが1回以上スケジュールされた」ことを記録するための、CPU個のビット配列の排他処理です。4000個のCPUが同じスピンロックを取りにいったら、競合するに決まっています。従来のRCUはまさにこの問題を抱えていました。
そこで、Tree RCUではこのCPUビットマップを分割し、64CPUをハンドリングするビットマップを64個作ることで競合を減らしています（64×64＝4096CPU）。なお、ここでは2段のTreeを説明しましたが、最大3段までサポートしているので、理論的に適用可能な最大CPU数は64×6×64＝26万2144CPUとなります。Paul、考え過ぎです。
さて、ここまでだと、世の中の99.999％の人にはまったく恩恵のないパッチで終わってしまうのですが、1つ非常に素晴らしいfeatureが追加されています。それは省電力サポートです。
従来のRCUはその動作原理上、一切仕事がなくdeep sleepしているCPUも、わざわざ1回起きてきてRCUのコールバックを呼び出し、CPUビットマップをONにしなければなりませんでした。RCU処理のたびに全CPUが動いていては、いつまでたっても消費電力が節約できません。
そこでTree RCUでは、idle関数に入りCステートを変える直前にRCUにもフラグを立てておき、CPUをいちいち起こさなくてもよいように工夫されています。
最近はサーバ分野でも消費電力はホットな話題ですから、恩恵を受ける人も多いのではないでしょうか。なお、現在はまだTree RCUはデフォルトではありませんが、2.6.30でデフォルトに変更される予定です。
■ファイルシステム・フリーズでスナップショット
エンタープライズにおける重要なストレージ要件の1つとして、スナップショット機能のサポートがあります。スナップショットとは、ディスクボリューム全体を瞬時に複製する技術で、主にバックアップと組み合わせて使われます。バックアップソフトが複製ボリュームを読み出している間も、業務アプリケーションは主ボリュームに対して通常どおりファイルに読み書きできるので、バックアップのためにサーバを停止する必要がなくなる、というわけです。
LinuxではLVMレイヤでこのスナップショットをサポートしていました。しかし最近のエンタープライズストレージ製品の中には、ハードウェアレベルでスナップショット機能を備えるものが増えてきたので、これをキチンと使えるようにしたいという要望がありました。
なぜハードウェア側が機能を持っているのに、さらにソフトウェアでのサポートが必要なのでしょうか？ これはキャッシュが原因です。ファイルシステムがあずかり知らぬ所でブロックデバイスの複製を作った場合、デバイスへの書き込みが完了していないかもしれず、壊れたデータが取れてしまうことがあります。これでは何のためのバックアップか分かりません。
そのため、ファイルシステムのダーティデータをすべてデバイスに反映させ、かつスナップショット作成中に新規書き込みがデバイスに対して始まらないことを保証してスナップショットを取る必要があります。
Takashi Satoは、Linuxファイルシステムはすでに、このような「同期＋新規書き込み拒否」インターフェイスをLVMスナップショット用に持っており、ユーザー空間に適切に公開されていないことだけが問題であることを明らかにしました。そして、プロプライエタリ・ファイルシステムレベルのファイルシステム・スナップショット機能がLinuxにも必要だと説きました。
実は、XFSはすでに、XFS専用ioctlとしてこのような仕組みを実装しており、実績もありました。これをファイルシステム非依存な形で再実装するという彼の提案は、好反応で迎えられます。
| 関連記事： | |
|
64bitファイルシステム XFSの実装（＠IT Linux Square） |
しばらくの間、ファイルシステム・フリーズした後、アンフリーズするのを忘れた場合の挙動について意見が割れ、なかなか議論が収束しませんでしたが、最終的に「タイムアウトによる自動アンフリーズはやはり副作用が大き過ぎるし、そんなばかを救う必要はない」という方針で合意が成立、無事マージされました。
余談ですが、いまちょうどLKMLにおいて「フリーズ中もmmap経由の書き込みは止まらないから、まだ考慮が足りないんじゃないのか？」といい出した人がいて、議論が進んでいます。2.6.30に間に合うかな？
| 3月版へ |
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」コマンドです。
 |
|
|
|
|
