sedfスケジューラの実装を理解する【後編】：仮想マシンモニタ Xen 3.0解読室（4/4 ページ）

[高橋浩和（VA Linux Systems Japan），ITmedia]

ドメインスケジューラの課題

　Xenのドメインスケジューラは、実装が単純で比較的効率的に機能します。しかし、まだうまく扱えないものもあり、特に多くのCPUを搭載したマルチプロセッサ構成やNUMAを苦手としています。Xen 3.0では、マルチプロセッサ対応のゲストOSを動作させられるようになりました。しかし、CPU時間を分割して各ドメイン（仮想CPU）に割り当て、順番に実行するという仮想マシン環境の性格上、ゲストOS内部でスピンロックを利用した排他処理と相性が良くありません*。

　Xenからは、ゲストOSの状態が見えないため、スピンロックを握った状態（排他区間実行中）の仮想CPUから、実行権を奪ってしまうことがあります。その場合、同じスピンロックを握ろうとしたほかの仮想CPUが、非常に長い時間にわたってビジーウェイトすることを強いられてしまいます（図3）。この現象は、ゲストOSのマルチプロセッサ対応度合いが低いほど、顕著に現れます*。

図3　ゲストOSのスピンロック

　これは、ゲストOSが割り込みを禁止しても同じです。ゲストOSが幾ら割り込みを禁止したところで、仮想CPUに対する仮想割り込みが禁止されるだけで、実CPUへの実割り込みの発生は抑制できません。そのためゲストOSの割り込み禁止区間であっても、実割り込みが発生し、仮想CPUの再スケジューリングが行われてしまいます。

　準仮想化ドメインであれば、ビジーウェイト状態になったことをゲストOSが明示的にXenに通知し、スピンロックを握ったまま割り当て時間を使い果たした仮想CPUを再実行させる仕組みなどを実装することが考えられます。しかし完全仮想化ドメインでは、ゲストOSに依存したそのような実装は不可能であるため、別の対策が必要です。ギャングスケジューリング方式の採用もその候補の1つです。ギャングスケジューリング方式とは、同じドメインに属する仮想CPUを一斉に実CPUに割り当てることで、この問題を解決しようというものです。

　また、NUMA対応がなされていないことも、今後の強化点の1つです。これはドメインスケジューラだけではなく、メモリ管理機能と合わせて設計する必要があります。メモリの距離を意識して各ドメインにメモリを割り当て、さらにそれに合わせて、ドメインを動かす実CPUを決定する必要があるでしょう。

最後に

　さて、これまで数回にわたって、ドメインをスケジューリングし実行権を与える仕組みを見てきました。次回からは、割り込み処理をはじめとした、「事象を制御するための機能」について見ていくことにします。

　ハードウェアで発生した事象をXenに伝える通常の割り込み処理以外にも、Xen内部で発生した事象をドメインに通知する「仮想割り込み」の仕組みなどがあります。また、これらの仕組みを利用して、ドメイン間通信や時計の機能などが実装されています。

　これらのうち、まずはハードウェア割り込みの制御部分を中心に、解説を始めることにしましょう。

このページで出てきた専門用語

ゲストOS内部でスピンロックを利用した排他処理と相性が良くありません

スピンロックは問題が顕著に現れるが、Linuxカーネル2.6のシーケンスロックなども悪影響を受ける。

この現象は、ゲストOSのマルチプロセッサ対応度合いが低いほど、顕著に現れます

実CPUよりたくさんの仮想CPUを使うゲストOSも動作させられるが、この場合さらにスピンロック問題が顕著になる。

本記事は、オープンソースマガジン2006年7月号「仮想マシンモニタ Xen 3.0解読室」を再構成したものです。