あと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以降はこのあたりの動きにも注目するとおもしろいかもしれない。