9月版　帰ってきたCon Kolivas、大論争を呼ぶの巻

小崎資広
2009/10/14

「オレはもっといいデータを持ってるぜ」

　Serge Belyshevは、さらに詳細な測定により、このような結果が出た原因の究明を図ります。

　クアッドコアマシンでmake -j4でカーネルビルドを実行したときの性能を測定した結果、興味深い結果が得られた。メインラインカーネルはv2.6.23（CFSが導入された版）に比較して、10％以上性能が落ちていることが判明した。

　詳しく説明する。

　下のグラフは、横軸がカーネルバージョン、縦軸がクアッドコア上のmake -j4カーネルビルドで必要とした時間（9回以上測定した中央値）である。現在のtip/master（注3）のスケジューラは、メインラインのものよりもよい。しかしBFSはそれよりもはるかによい性能を示しており、これはv2.6.23とほぼ同じである。

クアッドコア上でmake -j4でカーネルビルドを行った結果（Serge Belyshevの投稿より）（クリックすると拡大します）

　下のグラフは、makeの-jオプションを変化させることにより、並列ジョブ数と所要時間の関係をプロットしたものである。BFSは-j4（CPUと同じ並列数のとき）が一番速く、tip/masterでは最悪である。メインラインでも測定したが、tipよりも若干遅いだけで、似たような結果になった（のでここには載せない）。

makeの-jオプションを変化させた際の結果（Serge Belyshevの投稿より）（クリックすると拡大します）

　結論としては、

メインラインのスケジューラはv2.6.23よりリグレッションしている
BFSはCPU数と同じ並列ジョブに対して最適なパフォーマンスを発揮する。一方メインラインのスケジューラはそれとはほど遠い

注3：tipツリーはIngo Molnarが管理する開発ツリー、tip/masterはsched-develを含むtip上のさまざまなトピックブランチからLinusツリーへの送付が間近なパッチをマージして作った、テスト用ブランチ。

　この後のメールで、測定条件についていくつか追記が加えられました。

I/Oの影響を排除するため、ファイルシステムはtmpfsを使用
計測前にファイルキャッシュは捨てている
マシンのRAMは8GBである

　その後、彼はv2.6.23との比較に注目し、グラフに再計測結果をいくつか書き加えます。

・v2.6.24からv2.6.29までのそれぞれのリリースの性能

v2.6.24からv2.6.29までの性能比較（Serge Belyshevの投稿より）（クリックすると拡大します）

・並列数比較において、v2.6.23を追記

v2.6.23を加えた比較（Serge Belyshevの投稿より）（クリックすると拡大します）

　これは非常に興味深いデータです。なぜなら、

BFSよりもv2.6.23の方が良い結果を示した。よって着目すべきは、BFSの速度向上手法ではなく、CFSのリグレッションである

v2.6.24で非常に大きなリグレッションが観測されている。v2.6.24はCFSにさまざまな新機能が追加された版であるので、これは1つのキーになりそうだということが分かる

からです。

レイテンシ・ベンチマーク「latt」へのハック

　このように次々と出てくるベンチマーク結果に対し、BFSユーザーの何人かが、自身の体験を基に、「BFSがさまざまなデスクトップ利用シーンにおいて体感速度の向上をもたらしており、それはベンチマークで計測できないかもしれないが、価値のあるものだ」と主張しました。

　しかしながら多くのデベロッパは、「測定不可能はあり得ないので、ベンチマークか計測手段に問題があるだけだろう。フィーリングの議論をするよりは、新しいベンチマークを作った方が建設的だ」との立場を取り、そうした意見は通りませんでした。

　Jens Axboe（ブロックレイヤのメンテナ）も同じようなことを考えていたらしく、レイテンシ測定ソフトのlatt（注4）をその日のうちにハックします。これは、

アプリケーションはpipeを作成し、forkする。子プロセスはpipeを読んでブロックする・親プロセスはランダムな時間（200ms～2s）スリープする。起床後現在時刻を取得し、それをpipeに書き込む
子プロセスは起床後、現在時刻とpipeから受け取った時刻の差分をログに書き込む

という動作をすることにより、レイテンシを測定するベンチマークでmakeなどのシステムに負荷を掛けるコマンドと組み合わせて、負荷が掛かっている状態でのレイテンシを測定します。

注4：lattの最新版はgit://git.kernel.dk/latt.gitで公開されています。

Mike、孤軍奮闘す

　時を同じくして、Ingo Molnar、Nikos Chantziaras、Mike Galbraithらの手によって、スケジューラの機能ごとの性能劣化度合いの検証が行われました。/sys/kernel/debug/sched_featuresを使い、スケジューラの機能を1つ1つOFFにしていき、性能の増減を確認していったのです。

　これにより「NEW_FAIR_SLEEPERS」が大きな性能リグレッションを起こしていることが確認されました。NEW_FAIR_SLEEPERSとは、いままでスリープしていたタスクが起床したときに一時的にスケジューリングされやすくする仕組みです。v2.6.24で、v2.6.23のFAIR_SLEEPERSをイチから再実装したときに、NEW_FAIR_SLEEPERSという名称に変更されました（紛らわしいですが、タスクを新しく生成したときには影響を与えないボーナスです）。

　Mikeは次々と詳細な解析を行っていき、ほかにも、

child_runs_first
デフォルト・レイテンシターゲット値
カーネルスレッドのデフォルトnice値

が、レイテンシに悪影響を与えていることを突き止めました。

■コラム　CFSのチューニング

　あまり知られていませんが、CFSは非常に柔軟なチューニング・パラメータを持っています（昔、David Millerとフェイスツーフェイスで話したときに「あれを理解している人は誰もいないよ」と断言された記憶が……）。

　主に、以下の3つのチューニング・パラメータの設定個所があります（ただし、いくつかはカーネルビルド時にCONFIG_SCHED_DEBUGが必要）。

1.debugfs

　すべてのパラメータはbool値を取り、prefixにNO_を付けることにより、偽に設定できます。一番大きなくくりでの機能のON／OFFを制御します。

% cd /sys/kernel/debug/

          % cat sched_features

          NEW_FAIR_SLEEPERS NO_NORMALIZED_SLEEPER ADAPTIVE_GRAN WAKEUP_PREEMPT START_DEBIT                         AFFINE_WAKEUPS CACHE_HOT_BUDDY SYNC_WAKEUPS NO_HRTICK NO_DOUBLE_TICK ASYM_GRAN LB_BIAS

          LB_WAKEUP_UPDATE ASYM_EFF_LOAD NO_WAKEUP_OVERLAP LAST_BUDDY OWNER_SPIN

        
 % echo NO_NEW_FAIR_SLEEPERS > sched_features

2. /proc（グローバル・パラメータ）

　それぞれの機能の閾値の微調整ができます。

% cd /proc/sys/kernel

          % ls sched*

          sched_child_runs_first  sched_migration_cost      sched_rt_runtime_us

          sched_compat_yield      sched_min_granularity_ns  sched_shares_ratelimit

          sched_features          sched_nr_migrate          sched_shares_thresh

          sched_latency_ns        sched_rt_period_us        sched_wakeup_granularity_ns

3. /proc（スケジューラドメイン・パラメータ）

　あるcpuだけでパラメータを調整するといった用途に使います（まず使いませんが）。

% cd /proc/sys/kernel/sched_domain/cpuXX/domainXX

          busy_factor  cache_nice_tries  forkexec_idx  imbalance_pct  min_interval  newidle_idx

          busy_idx     flags             idle_idx      max_interval   name          wake_idx

2/3

Index
Linux Kernel Watch　9月版　帰ってきたCon Kolivas、大論争を呼ぶの巻

	Page 1 　What's BFS？メンテナからの回答は「CFS有利」
	Page 2 　「オレはもっといいデータを持ってるぜ」　レイテンシ・ベンチマーク「latt」へのハック　Mike、孤軍奮闘す　コラム　CFSのチューニング
	Page 3 　本邦初？あまり知られていないCFS概略　コラム　スケジューラ・パラメータのチューニング　さて、Mikeのパッチは何を変えたのか

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

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

Linux ＆ OSS フォーラム新着記事

【 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」コマンドです。