1月版 スケジューラの挙動は三巨頭会談で決まるのだ？
小崎資広
2009/1/30
まだまだあるぞ新機能
■IO CPU affinity
従来、I/O完了処理はI/Oデバイスからの割り込みが上がったCPUで行われていたので、どのCPUで処理されるかは、実質irqbalanceデーモンの胸先三寸でした。今回Jens Axboeの手によって、「IO CPU affinity」という設定（注3）をONにすることにより、I/O完了処理をI/O発行CPU（注4）で行えるようにするオプション機能が追加されました。
昔のPCはバスが共有バスだったので、どのCPUからSCSIコマンドを出すかはあまり重要ではなく、空いているCPUで処理するのが正しかったといえます。
NUMAマシンやポイント・ツー・ポイントでメモリやI/Oと接続されているイマドキのCPUでは、ターゲットI/Oデバイスから近いCPUと遠いCPUができてしまいます。データベースなどの用途で、せっかくCPU-I/Oトポロジを意識してI/O発行CPUを調整しても、折り返し処理が全然違うCPUで処理されてしまっては効果半減、というわけでした。
この追加オプションによって、system timeを最大40％ほど削減できたと報告されています。
Windowsでも、Windows Server 2008において類似の機能が提供される予定だとアナウンスされており（注5）、NUMAトポロジ対応は時代の趨勢（すうせい）といえそうです。
| 注3："echo 1 > /sys/block/[block_device]/queue/rq_affinity"と実行します 注4： マルチコアの場合、コア内の先頭CPUを選ぶようになっているので、同一コア内でバスを取り合う状況は回避されるようになっています。 注5：面白いことにWindowsでは、この機能はオプションではなく、全I/Oが対象となるみたいです。でも、よほど個々のI/Oの処理が重くない限り、割り込み処理を別CPUにマイグレートするとコスト的に引き合わないケースが多々出てくると思うのですが、大丈夫なんでしょうか？ |
■ブロックレイヤのSSD向け改善
最近のATAコマンドでは、接続先デバイスがSSDかどうかの情報を取得できるようになっており、それに対応した改善が入りました。
1点目は、シークを削減するために入っていたI/Oスケジューラ（注6）です。これはリクエストを受け取ってもすぐさまI/Oを発行せず、しばらく後続I/Oを待つことがあります。しかし、デバイスがNon-rotating mediaだった場合（注7）は、この待ち処理をスキップし、レイテンシを改善しています。
2点目は、以前紹介したセクタ破棄リクエストによるウェアレベリングの改善であり、SSDの長寿命化に一役買っています。
面白いと思ったのは、Windows 7ではSSD対応に際して、（プレス発表によれば）「SSDを、HDDではない別のストレージデバイスとして認識する」という仕様を選び、一方Linuxは、HDDとして認識するけれども内部的な動作が変わるようになっているということです。
筆者はLinux方式の方がスマートで好きですね。/dev/sdXという名前が変わってしまうと非互換になるので面倒ですし……。
| 関連記事： | |
 |
8月号 SSDドライブの耐用年数を増やすセクタ破棄リクエスト http://www.atmarkit.co.jp/flinux/rensai/watch2008/watch08b.html |
| 注6：今回の改善は、ASとCFQの改善です。 注7：ATA8の規格上、Non-rotating mediaは回転数（HDDに書いてある「7200rpm」とかいう値）を問い合わせると1rpmを返すことになっており、OSは、この特殊な値をSSDの判別に利用してもよいことになっています。 |
ついにLinuxにもadaptive lock導入か?!
btrfsのマージレビューの中の議論の1つに、再利用可能にできるはずのライブラリを内部にいくつも抱えていることによる見通しの悪さがありました。中でも特に議論を呼んだのは、spin lockとmutexを組み合わせて作ったadaptive lock実装でした。
adaptive lockとは、Solarisなどで採用されているロック方式で、一定時間ビジーウェイトで待った後、通常のブロック型のmutexに縮退するというハイブリッド型のロックです。Linuxにおいても、過去何回かSolarisスタイルのadaptive lockが提案されてきましたが、どれも性能がイマイチだったこととLinuxカーネルの設計方針に合致しなかったため、マージされませんでした。
Solarisスタイルのadaptive lockの問題点は、どのくらいの時間スピンするのが最適かは結局ケースバイケースなので、どのように設定してもうまくいかないケースが出てくることです。また、すでにロック保持タスクが別のロック待ちやI/O待ちで寝ているにもかかわらず、ビジーウェイトでロック解放を待つという状態は、CPUの浪費以外の何ものでもなく、複数のロックがネストしているような現実的なケースで性能が出ないことも問題でした。
端的にいうと、このロックで性能が向上するケースというのは、ロック分割が不十分で、ロック期間が十分短いことが保証されなくなってしまっている、あまり練れていないデータ構造のときに限られます。そのためむしろ「データ構造の方を再設計するべきでは？」という方向に話が向かってしまうわけです（注8）。
つまりLinusは、ダメな設計でもそこそこ性能が出る仕組みを用意してしまうことにより、カーネルデベロッパがちゃんとデータ構造を考えなくなることがイヤなんですね。
ところが、この議論の途中でさっそうと登場したのがPeter Zijlstra（注9）。「もっといいadaptive lock実装を-rtツリーからバックポートしたよ。これでmutexが全部adaptive lockになる」とLinusに提案します。
この提案は過去の提案とは異なり、時間によってspinとblockを切り替えるのではなく、ロック保持タスクが別CPUで動いているときはspinに、寝ているときはblockにと切り替えるというポリシーになっており、Linusの嫌いな、根拠のないヒューリスティクス（注10）が排除されているのが特徴。つまり、
| Pros. | ||
| ・従来のspin lockユーザーはruntime impactなしで、このロックに変換できる | ||
| ・mutexユーザーは、scheduleされなくなる分だけ速くなる | ||
| ・もしロック保持者がpreemptされスリープした場合、blockモードに即座に、かつ適切にフォールバックできる。よって、従来のadaptive lockのように、preemptカーネルで性能がガタ落ちになったりしない | ||
| Cons. | ||
| ・struct mutexにownerフィールドが増えた分だけ、hotpathに影響が出る | ||
| ・同じくownerフィールド分構造体のサイズが増える | ||
| ・スピン競合により、CPUをより消費する可能性がある | ||
となります。
でも、「このスピン競合が問題になるようなら、それはそもそもデータ構造がおかしいのだから、そっちを直すべきで実質的に問題はないよ」というのがZijlstraの説明です。
このパッチは、Ingo MolnarのVFSベンチで2倍、btrfs＋dbench（注11）で1.5倍という華々しい成績を飾り、Linusも乗り気十分。「マージする方向でレビューするよ」といっています。
2.6.29のマージウィンドウはすでに閉じられてしまいましたが、Linusが直接レビューしたパッチは、デベロップメントサイクルのルールを無視してコミットされることが常態化しているので、まだ2.6.29でのマージのチャンスはありそう。先行きが楽しみです。
このパッチ議論で一番のポイントは、会話をしているのがPeter ZijlstraとIngo MolnarとLinusの3人ということだったりします。
パッチの動作原理上、mutexの動きは、ロック保持者がスケジューラによって寝かされるタイミングでspinからblockへと変わらないといけません。つまり、スケジューラのコードに手を入れなければならないのです。
通常、スケジューラコードに別サブシステムの都合でコードを追加するのはご法度で、2万％「NAK」ものなんですが、主立ったスケジューラ関係者が集まって押せ押せムードで会話しているので誰も止められないという……（苦笑）。こういう具合に、人間関係が思わぬところで設計に反映されてしまうのもオープンソースの面白いところかもしれません。
| 注8：と、Linusたちは簡単にいいますが、現実的にはとても難しいので、プロプライエタリなOSの場合は開発コストが割に合わないと思います。これは誰かが「苦労の手間との兼ね合いが……」といった途端に、別の誰かが「じゃあ、オレがやってやる」といわれてしまうオープンソース特有の力学を反映しているのだと思います。 注9：Red hatのすご腕エンジニア。その活動はスケジューラ、futex、メモリ管理、rtmutex、lockdepなど、あり得ないぐらい多岐にわたっています。 注10：昔のLinuxのコードは、「経験則に基づいて途中で1.2倍する」とか、そういう適当なコードが大量にあり、実際に困った経験からきていると思われます。元々の数字に根拠がないので「うまくいかないケースが出てきたので数値を変えたい」と提案されたとき、影響範囲が見積もれなくてレビューできなくなってしまうのです。 注11：http://www.dbench.org/home/index.php。SambaのI/Oパターンをエミュレートしたディスクベンチマークで、ファイルサーバ性能をよく表すといわれています。 |
-stableの進ちょくはお休み
今月は上記の説明だけで分量オーバーになってしまったので、お休みです。ご了承ください。
 |
2/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」コマンドです。
 |
|
|
|
|
