仮想マシン間プロセススケジューリングの実環境への適用にむけて田所秀和（東工大）光来健一（九工大/CREST）千葉滋（東工大） 1 仮想マシン環境でのスケジューリング • 仮想マシン（VM）をつかったサーバ統合 – リソースの利用効率向上 • システム全体で優先度をつけにくくなる – Backup が他のサービスを阻害しないようにしたい VM1 VM2 – OSのスケジューリングのみ • WEB と backup 間に優先度はつけられない – VMスケジューリングを併用 • DBが止まった場合backupの優先度が高くなってしまう DB WEB backup 優先度 VMM Hardware 2 Monarch Scheduler [田所ら ‘08] (1/2) • 仮想マシンモニタがゲストOSのランキューを操作 – ゲストOSのスケジューリングポリシーを変更 • プロセスを止める：プロセスをランキューから外す • プロセスを再開：ランキューに戻す VM1 VM2 – ゲストOSの変更が不要 – ゲストOS内で特別あつかいするスレッドが不要 DB backup WEB VMM ランキューを直接操作 3 Monarch Scheduler [田所ら ‘08] (2/2) • システム全体でプロセスに優先度をつける • ポリシー例 – Backupの優先度最低 • 他のサービスを阻害しないよう – WEB or DBが動いているときはbackupを停止 • VMMが定期的にゲストOSを調査 VM1 VM2 DB WEB 優先度 backup 優先度最低 VMM Hardware 4 本発表：MonarchSchedulerの拡張 • I/Oバウンドプロセスの制御 – ランキューに載りにくい • 定期的にチェックする方法では難しかった • 約74％はI/O待ち – iozoneで調査 • WindowsゲストOSに対応 – Linuxとは違う • ソースコードが無い • 公開情報が少ない • シンボルのアドレスがロード時まで不定 5 I/Oバウンドプロセス制御の問題(1/2) • プロセスをウェイトキューから除く – ウェイトキューの発見が難しい • さまざまな場所に存在 – nfsはモジュールのロード時にヒープに生成 • ランキューは起動時に生成され、CPU毎に存在 – 単純に戻すだけでは再開させられない可能性 • 永遠にI/O待ちの可能性 • 定期的に調べるだけでは、I/Oが完了したか不明 6 I/Oバウンドプロセス制御の問題(2/2) • ゲストOSのI/Oスケジューラでの操作 – I/Oリクエストを止めれば、発行したプロセスが止まる – リクエストが存在する時間が短い • ドメイン０での操作 – フロント、バック間のリクエストの対応付けが難しい – リクエストとプロセスの対応が難しい Xen I/O アーキテクチャドメイン０バックエンド実ドライバドライバドメインU I/O Scheduler フロントエンドドライバ Xen VMM ハードウェア 7 プロセスの状態変更で制御 • I/O待ちプロセスの状態を書き換え – {,UN}INTERRUPTIBLE を STOPPED に – I/O完了時に自発的に止まる – 通常ならI/O完了時にRUNNINGになりランキューへ • 再開させるときは、ランキューに挿入 – 状態をRUNNINGにしてから interruptible VMM stoppedに変更 stopped interruptible stopped I/O完了後 VMM VMM 8 Windowsでのランキューの位置特定 • VMMから直接発見する方法は不明 – LinuxではGSレジスタからたどれる – デバッガを使っても直接は不明 – レジスタからたどれるか不明 Linuxの場合 Linuxのメモリ GSレジスタ x8664_pda ランキュー struct x8664_pda { task_t * current; ulong data_offset; …}; data_offset + PER_CPU_RUNQUEUES 9 Windowsのランキュー位置推定 • PsActiveProcessHeadの発見が目標 – PsActiveProcessHeadから固定長離れている – PsActiveProcessHeadはプロセスリストの先頭 Windows Kernel 実行中プロセス実行待ちプロセスアイドルプロセス ProcHead current 固定長離れている summary 実行待ちリスト配列 IRQL ランキュー VMM 10 プロセスリストの発見 • プロセス候補をメモリ全体から探す – Xenのスナップショット機能を利用 – プロセス型を表すビット列を探索 • オブジェクトは型を表すヘッダを保持 • GREPEXEC [bugcheck ’06] を利用 • プロセスかをチェック – 実行ファイル名がアスキー文字 – プロセスIDが４の倍数 – プロセス全体が一つの環状リストになっている 11 PsActiveProcessHeadの発見 • プロセスとはアドレスが異なる – プロセスの上位３２ビットは 0xfffffa80 – ProcHeadの上位３２ビットは0xfffff800 % ./search_mem ~root/debutante.save 0 Idle priority: 0 next: 0xffffffffffffff18, prev: 0xffffffffffffff18 4 System priority: 8 next: 0xfffffa8002c97c10, prev: 0xfffff800017ad338 2212 WmiPrvSE.exe priority: 8 next: 0xfffffa8001659c10, prev: 0xfffffa8002f1ab50 2424 explorer.exe priority: 8 next: 0xfffffa8002f1ab50, prev: 0xfffffa80036c5040 2200 taskeng.exe priority: 8 next: 0xfffffa8003696a40, prev: 0xfffffa80035c3040 2248 rdpclip.exe priority: 8 next: 0xfffffa80036c5040, prev: 0xfffffa8003680040 2316 dwm.exe priority: 8 next: 0xfffffa80036d66c0, prev: 0xfffffa8003696a40 4 priority: 0 next: 0xa800000009ff18, prev: 0x1fff1c ….. 1112 svchost.exe priority: 8 next: 0xfffffa800307dc10, prev: 0xfffffa8002f58c10 680 logon.scr priority: 4 next: 0xfffff800017ad338, prev: 0xfffffa8000c9fc10 12 Windowsでのランキューの一貫性 • ランキューが操作されていないときのみ、ランキューを操作 – Linuxの場合は、スピンロックをチェック – VMMが割り込み要求レベル(IRQL)をチェック • SYNCH_LEVEL以上なら、スケジューリング中の可能性 • SYNCH_LEVEL未満なら、スケジューリング中でない Linuxのスケジューラ schedule() { spin_lock(runqueue); ランキューの操作 spin_unlock(runqueue); }; 13 実験 • 目的 – Linuxで、I/Oバウンドプロセスを制御できるか – Windowsで、ランキューの位置特定にかかる時間 – Windowsにおける、スケジューリングの挙動 • 実験環境 • Core2Duo 2.4GHz、メモリ6Gbyte • Xen 3.3.0 (x86_64) • ドメイン0 ：Linux 2.6.18.8、メモリ2Gbyte • ドメインU：Linux 2.6.16.33, Windows Vista SP1、メモリ1Gbyte 14 実験：I/Oバウンドプロセスの制御 • iozoneを制御 – ディスクベンチマークツール • CPU時間の増加量から、実行を判断停止中ドメイン０ドメインU Monarch Scheduler iozone Xen VMM 15 実験：ランキューの位置特定時間 • ドメインUのメモリサイズを変化 • メモリイメージを書き出す場所を変化 – 実ディスク – tmpfs • メモリサイズに比例 • ディスクI/Oがボトルネック 16 実験：スケジューリングの挙動 • 4つのプロセスをスケジューリング – ドメインU1で3つ、ドメインU2で1つ – プロセスは円周率の計算 • PI1 の優先度を最低ドメインU1 ドメインU2 PI2 PI3 PI4 PI1 優先度最低 Xen VMM 17 関連研究 • ゲストOSの情報を使いVMをスケジューリング – Task-aware VM Scheduling [VEE’09 Kim et al.] • Gray-box知識を利用 – Guest-aware VM Scheduling [europar’08 kim et al.] • ゲストOSからプロセスの優先度情報を取得 • Windowsの内部情報に依存した手法 – VMwatcher [CCS’07 Jiang et al.] • GREPEXECを使いプロセスを推定 – Lares [PS’08 Payne et al.] • ゲストOSにカーネルモジュールを追加 18 まとめと今後の課題 • まとめ – Monarch Schedulerの拡張 • VMMからI/Oバウンドなプロセスを制御 • WindowsゲストOSにも対応 • 今後の課題 – WindowsでのI/Oバウンドプロセスの制御 – 現在実行中のプロセス制御 – 現実的なアプリケーションを対象とした実験 19