あと1週間ほどででリリース予定のLinuxカーネル3.4。今回もさまざまな機能強化が図られているが、逆にずいぶん前から変わらない部分も多い。その代表がデフォルトのI/Oスケジューラ「CFQ（Completely Fair Queuing⁠）⁠」である。2006年9月リリースのカーネル2.6.18以来、デフォルトスケジューラとしての地位を保ち続けているCFQだが、「⁠そろそろ次のデフォルトを考える時期に来ているのでは?」という声も出始めている。

CFQについての議論はカーネル開発者のメーリングリスト「LKML」でもしばしば行われている。その中でも4月10日にRed Hat所属のVivek Goyal氏が提示した「いまの時代、CFQがデフォルトスケジューラで本当に正しいのか」という一文からはじまる投稿が非常に興味深い。

Vivek Goyal: [RFC PATCH] block: Change default IO scheduler to deadline except SATA

URL：https://lkml.org/lkml/2012/4/10/198

この中でVivek氏は「CFQはたしかに回転速度の遅いSATAディスクや一部の低速なSASディスクには向いている。しかし、ストレージアレイやSSD、仮想ディスクではパフォーマンスが低下する」として、「⁠non-SATAディスクではデッドラインスケジューラをデフォルトにしたほうがよいのでは?」と投げかけており、実際にSATA以外のディスクでデッドラインスケジューラをデフォルトにするパッチを投稿している。

当然ながらLinux 3.4ではCFQがデフォルトスケジューラであることが決まっている。Linuxサーバが大量にデプロイされる大規模分散環境では、コストの安いSATAの需要はかなり高い。だが、分散環境下ではディスクI/Oがボトルネックとなりやすく、運用管理者にとってはつねに頭の痛い問題である。今後、SSDや仮想環境が普及していくにしたがい、スケジューラのパフォーマンスという問題はますます重要になってくるはずだ。

CFQに代わる候補としてはデッドラインスケジューラのほか、Noopなども挙げられている。ただしNoopに関しては「SSD以外ではかえって遅くなる」という指摘もあり、今後もベンチマークテストなど、さらなる検証が必要だろう。Linux 3.5以降はこのあたりの動きにも注目するとおもしろいかもしれない。