基礎から覚える 最新OSのアーキテクチャー 第10回

AMD FX向けにパッチで修正 スケジューラーが抱える難題

ハードウェアやシステム全体の動向に
合わせた進化を求められるスケジューラー

　Windowsに限らず、同時に実行されるスレッド数は年々増えていく傾向にある。ある時点で最適だったスケジューリングアルゴリズムも、スレッド数が100倍になっても最適とは限らない。また論理プロセッサーも増えていく傾向にあり、デュアルコア/デュアルプロセッサーのシステムと、128物理プロセッサー/256論理プロセッサーのシステムで、同じプロセッサー割り当て手法が有効であるとも限らない。OSも計算操作主体のものと、サーバーなどファイルや通信などが大量に発生するものでは、効率が変わってくる。

　そしてスケジューリングアルゴリズムは、プロセッサーの特性やコア数などにも大きな影響を受ける。最近の話題でいえば、AMDのBulldozerコア(AMD FXやOpteron)に対するWindowsのパッチ提供がその好例だ。パッチ以前のWindowsは、Bulldozerコアを8物理コア/8論理コアプロセッサーのプロセッサーとして認識していた。しかしパッチを当てると、4物理コア/8論理コアプロセッサーのプロセッサーと認識の仕方を変える。これにより、物理プロセッサー単位での割り当てを優先して、論理コア同士の実行に影響が出ないように、リソースを共有する片方の論理コアを同時に使わないよう割り当て方法を変更する。

　この仕組みは、インテルCPUのハイパー・スレッディング・テクノロジー(HT)に最適化するときに、Windowsに組み込まれたものだ。HTでは、ひとつの物理プロセッサーで実行される2つのスレッドは、短い時間で見ると実行効率が違っていた。というのは、HTはCPU内部の演算器などのリソースを“遊ばせない”ようにするための仕組みであり、実現方法が簡易な仕組みだったため、短い時間で見ると2つの論理プロセッサーの実行効率が違ってしまったのである。だがHTでも長い時間で見ると、平均して両方の論理プロセッサーの実行効率は同程度になる。

　CPUのシングルスレッド性能に依存するような処理を考えると、2つの論理プロセッサーを同時に使うよりも、空いているなら別の物理プロセッサーで実行させたほうがいい。そこで、CPUにスレッドを割り当てるときに、物理プロセッサーが分かれるように割り当てる方式にWindowsを変更したわけだ。

　今回のAMD向けパッチはこの仕組みを利用したものであろう。しかし提供後のベンチマークテストでの評価を見てもわかるように、必ずしもプロセッサーの最大性能を出し切ってはいないようだ。Bulldozerコアの仕組みはインテルのHTとは実装が異なるもので、リソースの競合はあるものの、ハードウェアを共有していない部分もある。そのため1つの物理プロセッサーに含まれる2つの論理プロセッサーで同時に処理を行なわせても、HTほど効率が落ちる可能性は少ない。

　しかしWindowsのスケジューリングアルゴリズムは、スレッドを物理プロセッサー単位で割り当てることを、優先することしかできない。今回のパッチはどちらかというと、CPU割り当てにより効率が極端に落ちてしまう可能性を防ぐもの、という視点で作られているようだ。例えば、ある物理プロセッサーがアイドル状態なのに、すでにスレッドを実行している別の物理プロセッサーの論理プロセッサーに、スレッドを割り当ててしまうような状態を防ぐというわけだ。

　スケジューラーはカーネルの根幹ともいうべき部分であり、その改良は大規模な変更となりがちで、広範囲な検証を必要とする。スケジューリングはいわゆるディスパッチャーだけでなく、メモリー割り当てやI/O制御などでも行なわれるもので、ディスパッチャーだけを改良しても効率を改善できるとは限らないからだ。そのためわずかな変更ならともかく、大きな改良はOSのメジャーバージョンアップでもないかぎり困難だ。

　そうした理由もあって、Bulldozerコアに向けた改良は、既存の仕組みを利用したパッチになったと思われるが、本格的な改良が可能だったとしても、プロセッサーの特性に合わせたカーネルの改良は難しいと思われる。例えばHTのように、「1つの物理プロセッサーに所属する、2つの論理プロセッサーの片方だけを優先する」というのは、簡単に判断できる。しかしBulldozerの場合、浮動小数点ユニットは共有しているものの、整数演算ユニットは独立している。浮動小数点演算の少ないコード同士なら、同じ物理プロセッサー内の論理プロセッサーに割り当てても、高速に実行できる可能性は高い。

　しかし、単純にコードを見て浮動小数点演算命令が少ないといっても、浮動小数点演算にかかる時間が短いとは限らない。ループで同じ命令を何度も繰り返すといった可能性があるからだ。スケジューラーがコード内容まで見てアルゴリズムを切り替えることは困難だし、しかもそれはBulldozerコアの場合の話で、他のプロセッサーではまた事情が違ってくる。

　しかも最近のシステム動向を見ると、スケジューラーの動作は「軽い」ことが求められるようになってきている。LinuxがO(1)スケジューラーを採用したのは、スケジューラーの実行時間をなるべく短くするためだ。大量のスレッドを実行すると、単位時間あたりのスレッド切り替えの回数が増える。また、多くのOSにGUIが搭載されており、その反応を良くするために高い優先度のスレッドで動き、制御を横取りする可能性も高くなった。そのため、単位時間あたりでスケジューラーのコードを実行する回数が増え、全体の実行時間に占める割合が無視できないほどになる可能性が高いからだ。

　ハードウェアの進化やシステムのトレンドに合わせた変化を、スケジューラーも求められているわけだが、そのニーズを完全に満たすのはなかなか難しいだろう。