sedfスケジューラの実装を理解する【前編】:仮想マシンモニタ Xen 3.0解読室(3/3 ページ)
現在のXenでは、2種類のスケジューリング方針を提供しています。ここでは標準スケジューリング方式であるsedfスケジューラの実装について解説していきます。
プリエンプション
sedfスケジューラは、方針1-2のとおりデッドラインに最も近い仮想CPUに実行権を与えます。実行権を使い切った仮想CPUは、(方針2、方針3で与えられた実行時間がなければ)次の周期に入るまで、スケジューリング対象になりません。ある仮想CPUが実行権を使い切ると、次はデッドラインに最も近い仮想CPUに実行権を与えます。
仮想CPUの実行中に、新しい仮想CPUがスケジューリング対象に加わることがあります。例えば、
- ある仮想CPUが次の周期に入った場合
- 待機中の仮想CPUが起床した場合
です。この場合、sedfスケジューラはどのように動くと思いますか? Linuxのプロセススケジューラでは、現在実行中のプロセスの実行優先度と、スケジューリング対象に加わったプロセスの実行優先度を比較し、後者の実行優先度が高ければプリエンプションを発生させます。
実はsedfスケジューラは、この場合プリエンプションを発生させません。新たにスケジューリング対象に加わった仮想CPUのデッドラインが、現在実行中の仮想CPUより近くても、プリエンプションを発生させないのです。現在実行中の仮想CPUが持ち時間を使い切るか、自発的にCPUを手放すまでドメイン切り替えは行いません。sedfスケジューラは、ドメイン切り替えによるオーバーヘッドを避ける方を優先しています*。
ただしこの方針は、現在実行中の仮想CPUが方針1-1で与えられた割り当て時間を利用して動作している場合の話です。先ほどお話ししたように、持ち時間はほかにも方針2や方針3で与えられることがあります。異なる方針で与えられた時間で動作している仮想CPU間では、プリエンプションが発生します(表1)。
与えられた時間の種類 | 優先度 |
---|---|
方針1-1で与えられた標準の割り当て時間 | 高 |
方針2で与えられた補償時間 | 中 |
方針3で与えられた有効利用時間 | 低 |
アイドルドメインが与えられている実行時間 | 最低 |
例えば、仮想CPUが方針2で与えられた補償時間で動作しているときを考えてみましょう。このとき、方針1-1で与えられた割り当て時間で動作する仮想CPUがスケジーリング対象になると、プリエンプションが発生します。また、仮想CPUが方針3で与えられた有効利用時間で動作しているときに、方針1-1による割り当て時間、もしくは方針2による補償時間で動作する仮想CPUがスケジーリング対象になると、これもプリエンプションが発生します。
スループットと応答性
Linuxカーネル2.6のプロセススケジューラは、スループットと応答性を両立させるために、魔法のコードを利用しています。プロセススケジューラは、基本的にはスループット指向のスケジューリングを行いますが、対話型プロセス*と思われるプロセスを検出し、特別に優先して実行権を与えているのです。これは、1回ごとの動作時間が非常に短いプロセスを、対話型プロセスと仮定することによって実現しています。
一方、Xenのsedfスケジューラはどうでしょうか? いままでsedfのスケジューリング方針を見てきましたが、この方式は、ドメインに対する公平なCPU時間割り当てと、スループットに主眼を置いています。
sedfスケジューラは、ドメインが割り当て時間を使い切るまで、ほかのドメインに実行権を譲ることはありません。ほかのドメインに対話処理などの応答性を要求する処理があってもです。そもそもXen(sedfスケジューラ)は、ゲストOS内で行われている処理で即応性が必要かどうか知ることができませんし、そもそも対話処理プロセスを動かすもととなるtty入力の割り込みや、ネットワークの割り込みをそのドメインに通知していません。
そのため、同じXen上にCPU負荷の高いドメインが存在すると、対話的な処理が中心のドメインで応答性が悪くなります。対話型プロセスはすぐに実行権を手放すため、対話型プロセスが中心となるドメインは、割り当て時間をすぐに放棄しがちです。一度割り当て時間を放棄すると、次の周期が来るまで、そのドメイン内のプロセスは実行が難しくなります。このため、負荷の低いドメインの中の対話型プロセスよりも、負荷の高いドメインの中の対話型プロセスの方が、応答性が良い状況も発生します。 この問題は、すべてのドメインのスケジューリング周期を短く設定すれば改善できます。オーバーヘッドは増えますが、一番簡単な回避策でしょう*。
次回は、sedfスケジューラのデータ構造とその実装をのぞいてみましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このページで出てきた専門用語
ドメイン切り替えによるオーバーヘッドを避ける方を優先しています
この方針は、将来的には変更される可能性がある。
対話型プロセス
シェルなど、ユーザーインタフェースをつかさどるプロセス群。
一番簡単な回避策でしょう
将来的には、対話型処理が必要なドメインを見つけ出し、優先的に実行権を与えるドメインスケジューラを設計するということもあり得る。
本記事は、オープンソースマガジン2006年7月号「仮想マシンモニタ Xen 3.0解読室」を再構成したものです。
関連記事
- ドメインのスケジューリング【後編】
- ドメインのスケジューリング【前編】
- ドメインの切り替え【後編】
- ドメインの切り替え【前編】
- Xenの内部設計【後編】
- Xenの内部設計【前編】
- Xenのモデルと構造
複数の仮想マシン環境を作り上げ制御するために、仮想マシンモニタであるXenが具体的に何をやっているのか、興味がある方に向け、Xenの設計思想と実装について連載で解説していく。
Copyright © ITmedia, Inc. All Rights Reserved.