仮想マシン間プロセススケジューリングの 実環境への適用にむけて 田所秀和 （東工大） 光来健一 （九工大/CREST） 千葉　滋 （東工大）

仮想マシン環境でのスケジューリング 仮想マシン（VM）をつかったサーバ統合 システム全体で優先度をつけにくくなる リソースの利用効率向上 Backup が他のサービスを阻害しないようにしたい OSのスケジューリングのみ WEB と backup 間に優先度は つけられない VMスケジューリングを併用 DBが止まった場合backupの 優先度が高くなってしまう VM1 VM2 優先度 DB backup WEB VMM Hardware

Monarch Scheduler [田所ら ‘08] (1/2) 仮想マシンモニタがゲストOSのランキューを操作 ゲストOSのスケジューリングポリシーを変更 プロセスを止める：プロセスをランキューから外す プロセスを再開：ランキューに戻す ゲストOSの変更が不要 ゲストOS内で特別あつかいする スレッドが不要 VM1 VM2 DB backup WEB VMM ランキューを直接操作

Monarch Scheduler [田所ら ‘08] (2/2) システム全体でプロセスに優先度をつける ポリシー例 Backupの優先度最低 他のサービスを阻害しないよう WEB or DBが動いているときはbackupを停止 VMMが定期的にゲストOSを調査 VM1 VM2 優先度 DB backup WEB VMM Hardware 優先度最低

本発表：MonarchSchedulerの拡張 I/Oバウンドプロセスの制御 ランキューに載りにくい 定期的にチェックする方法では難しかった 約74％はI/O待ち iozoneで調査 WindowsゲストOSに対応 Linuxとは違う ソースコードが無い 公開情報が少ない シンボルのアドレスがロード時まで不定

I/Oバウンドプロセス制御の問題(1/2) プロセスをウェイトキューから除く ウェイトキューの発見が難しい さまざまな場所に存在 nfsはモジュールのロード時にヒープに生成 ランキューは起動時に生成され、CPU毎に存在 単純に戻すだけでは再開させられない可能性 永遠にI/O待ちの可能性 定期的に調べるだけでは、I/Oが完了したか不明

I/Oバウンドプロセス制御の問題(2/2) ゲストOSのI/Oスケジューラでの操作 ドメイン０での操作 リクエストが存在する時間が短い ドメイン０での操作 フロント、バック間のリクエストの対応付けが難しい リクエストとプロセスの対応が難しい ハードウェア Xen VMM フロントエンド ドライバ バックエンド ドライバ 実ドライバ ドメイン０ ドメインU Xen I/O アーキテクチャ I/O Scheduler

プロセスの状態変更で制御 I/O待ちプロセスの状態を書き換え 再開させるときは、ランキューに挿入 {,UN}INTERRUPTIBLE を STOPPED に I/O完了時に自発的に止まる 通常ならI/O完了時にRUNNINGになりランキューへ 再開させるときは、ランキューに挿入 状態をRUNNINGにしてから interruptible VMM interruptible VMM stopped stopped VMM stoppedに変更 I/O完了後

data_offset + PER_CPU_RUNQUEUES Windowsでのランキューの位置特定 VMMから直接発見する方法は不明 LinuxではGSレジスタからたどれる デバッガを使っても直接は不明 レジスタからたどれるか不明 Linuxの場合 struct x8664_pda { task_t * current; ulong data_offset; …}; Linuxのメモリ GSレジスタ x8664_pda data_offset + PER_CPU_RUNQUEUES ランキュー

Windowsのランキュー位置推定 PsActiveProcessHeadの発見が目標 current IRQL 実行待ち リスト配列 ProcHead 固定長 離れている ランキュー Windows Kernel 実行中プロセス 実行待ちプロセス アイドルプロセス VMM summary

プロセスリストの発見 プロセス候補をメモリ全体から探す プロセスかをチェック Xenのスナップショット機能を利用 プロセス型を表すビット列を探索 オブジェクトは型を表すヘッダを保持 GREPEXEC [bugcheck ’06] を利用 プロセスかをチェック 実行ファイル名がアスキー文字 プロセスIDが４の倍数 プロセス全体が一つの環状リストになっている

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

Windowsでのランキューの一貫性 ランキューが操作されていないときのみ、ランキューを操作 Linuxの場合は、スピンロックをチェック VMMが割り込み要求レベル(IRQL)をチェック SYNCH_LEVEL以上なら、スケジューリング中の可能性 SYNCH_LEVEL未満なら、スケジューリング中でない Linuxのスケジューラ schedule() { spin_lock(runqueue); ランキューの操作 spin_unlock(runqueue); };

実験 目的 Linuxで、I/Oバウンドプロセスを制御できるか 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

実験：I/Oバウンドプロセスの制御 iozoneを制御 CPU時間の増加量から、実行を判断 ディスクベンチマークツール 停止中 iozone Xen VMM ドメイン０ ドメインU Monarch Scheduler

実験：ランキューの位置特定時間 ドメインUのメモリサイズを変化 メモリイメージを書き出す場所を変化 メモリサイズに比例 実ディスク tmpfs メモリサイズに比例 ディスクI/Oが ボトルネック

実験：スケジューリングの挙動 4つのプロセスをスケジューリング PI1 の優先度を最低 ドメインU1で3つ、ドメインU2で1つ プロセスは円周率の計算 PI1 の優先度を最低 Xen VMM ドメインU1 ドメインU2 PI3 PI4 PI1 PI2 優先度最低

関連研究 ゲストOSの情報を使いVMをスケジューリング Windowsの内部情報に依存した手法 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にカーネルモジュールを追加

まとめと今後の課題 まとめ 今後の課題 Monarch Schedulerの拡張 WindowsでのI/Oバウンドプロセスの制御 VMMからI/Oバウンドなプロセスを制御 WindowsゲストOSにも対応 今後の課題 WindowsでのI/Oバウンドプロセスの制御 現在実行中のプロセス制御 現実的なアプリケーションを対象とした実験