仮想マシン間にまたがるプロセススケジューリング田所秀和　　光来健一　　千葉滋東京工業大学

1

仮想マシン環境でのスケジューリング 仮想マシン (VM) を使ったサーバ統合

リソースの利用効率の向上 システム全体で優先度を付けたい

例 : DB > WEB > backupデータベースプロセスウェブプロセスバックアッププロセス

ウェブやデータベースのサービスを阻害させない

DB

backup

WEB

VM1 VM2

HardwareVMM

優先度

2

システム全体でのスケジューリングは難しい OS のスケジューリングと VM のスケジューリング

だけではうまくいかないOS のスケジューリングのみ

WEB と DB, backup 間に優先度はつけられない

VM1 ＜ VM2 DB が止まった場合、

WEB ＜ backup になってしまうVM1 ＞ VM2

DB ＜ WEB になってしまう

DB

backup

WEB

VM1 VM2

優先度

？

3

システム全体でのスケジューリングは難しい OS のスケジューリングと VM のスケジューリング

だけではうまくいかないOS のスケジューリングのみ

WEB と DB, backup 間に優先度はつけられない

VM1 ＜ VM2 DB が止まった場合、

WEB ＜ backup になってしまうVM1 ＞ VM2

DB ＜ WEB になってしまう

DB

backupWEB

VM1

VM2

優先度

4

システム全体でのスケジューリングは難しい OS のスケジューリングと VM のスケジューリング

だけではうまくいかないOS のスケジューリングのみ

WEB と DB, backup 間に優先度はつけられない

VM1 ＜ VM2 DB が止まった場合、

WEB ＜ backup になってしまうVM1 ＞ VM2

DB ＜ WEB になってしまう

DB

backup

WEB

VM1

VM2

優先度

DB が止まると backup が

動く

5

システム全体でのスケジューリングは難しい OS のスケジューリングと VM のスケジューリング

だけではうまくいかないOS のスケジューリングのみ

WEB と DB, backup 間に優先度はつけられない

VM1 ＜ VM2 DB が止まった場合、

WEB ＜ backup になってしまうVM1 ＞ VM2

DB ＜ WEB になってしまう

DB

backup

WEB

VM1

VM2優先度

6

VM 間で協調するスケジューラの問題 複雑なスケジューリングが必

要止めてはならないプロセス

スケジューリングスレッド自身無視すべきプロセス

syslogd

OS を変更する必要スケジューリングスレッドを

動かす

DB

backupWEB

優先度

協調してスケジューリン

グ

schedsched

7

仮想マシンモニタによるプロセススケジューリング 仮想マシンモニタ (VMM) が

直接ゲスト OS のランキューを操作ゲスト OS のスケジューリングポリシーを変更ゲスト OS の変更が不要

ポリシー例WEB または DB が動いているときは

backup を止めるVM1 ＜ VM2

WEB と DB だけが動いているときは、DB の優先度を最高にする

DB

backupWEB

VM1 VM2

VMMランキューを直接操

作 8

ゲスト OS のランキューを操作する手順 一定時間毎に全ての VM をチェック

1. VM を一時停止2. ゲスト OS がランキューを操作していないことを確

認 データ構造を破壊しないように ランキューを操作していたらそのまま VM を再開

3. ポリシーに従ってランキューを操作する4. VM を再開

9

システムの構成 スケジューラプロセス

ドメイン 0 のプロセスで実装ランキュー操作VM の優先度操作

ドメイン 0 はスケジュール対象外スケジューラプロセスが常に

動くようにドメイン 0 では通常のアプリ

ケーションは動かさない Xen VMM

sched

ドメイン 0ドメイン U ドメイン U

　

VMM として Xen を利用

ゲスト OS は Linux を対象

WEB

DB

backup

10

スケジューリングのためのランキュー操作 プロセスの一時停止

タスク構造体を取り除く プロセスの実行の再開

タスク構造体を戻す 注意点

ランキューにつながれたプロセスの数も更新 ゲスト OS の意味を保つ

実行中のプロセスは取り除かない OS 内のいろいろな場所にプロセスの情報が残っているので難

しい 今後の課題 11

一貫性を保ったランキューの操作 ゲスト OS が操作していないときのみランキュー

を操作VMM がランキューのスピンロックを調べる

メモリを読むことでチェックSMP カーネルを使用

SMP カーネルの場合スピンロックを用いて排他制御を行う

schedule() { spin_lock(runqueue); ランキューの操作 spin_unlock(runqueue);};

ドメイン U のスケジューラ

12

ドメイン U のカーネルメモリへのアクセス ドメイン U のページをドメイ

ン 0 上のプロセス空間にマップドメイン U の仮想アドレスが含

まれるマシンメモリのページ番号を求める

ページ境界をまたがないようにアクセス構造体のメンバ変数などメモリマップはページ単位

仮想アドレス

Xen VMM

ページテーブル

P2M テーブル

マシンメモリ

ドメイン Uドメイン 0

マップ

13

ドメイン U のメモリ操作のための型情報取得 カーネルのデバッグ情報から型情報を取得

カーネルを CONFIG_DEBUG_KERNEL=y でコンパイルデバッグ情報から型情報の取得には gdb を使用カーネルのコンフィグやマクロの解析が不要

コンパイラが解析する

% gdb vmlinux-debug(gdb) ptype runqueue_ttype = struct runqueue { spinlock_t lock; long unsigned int nr_running; long unsigned int cpu_load[3]; …}

struct runqueue { spinlock_t lock; unsigned long nr_running;#ifdef CONFIG_SMP unsigned long long cpu_load[3];#endif …}; ソースコード デバッグ情報

14

ランキューのアドレスの取得 仮想 CPU の GS レジスタから runqueue のアドレス

を取得Linux 2.6 では CPU 毎にランキューが存在レジスタの値は VMM へのハイパーコールを用いて取得x8664_pda は各 CPU 毎に固有のデータを管理 (x86_64)

GS レジスタ

struct x8664_pda { task_t * current; ulong data_offset; …};

x8664_pda

runqueue

ドメイン U のメモリ

data_offset +

PER_CPU_RUNQUEUES 15

スケジューリング性能を調べる実験

4 つの実験をおこなったドメイン U へのメモリアクセスによるオーバーヘッド優先度による性能の変化スケジューリングを行う間隔の影響プロセススケジューリングの挙動

環境 CPU: PentiumD 3.4GHz Memory: 2G (Dom0/DomU 　 1Gbyte/512Mbyte) Xen 3.0.4 (x86_64) Linux kernel 2.6.16.33

16

ドメイン U のメモリアクセスのオーバーヘッド ドメイン 0 のプロセスにドメイン U のメモリをマッ

プしてアクセス 仮想アドレスからフレーム番号の取得がボトルネッ

クゲスト OS のページテーブルを引くのに時間がかかるランキュー上のプロセスをたどるのに必要なマップの回数

最大 (42+ 実行待ちプロセスの数 )*VCPU の数 * ドメインの数

処理 時間（マイクロ秒）

ドメインの一時停止と再開 14.84

仮想アドレスに対応するフレーム番号の取得 68.95

ページをドメイン 0 のプロセスにマップ・アンマップ

13.72

1 ワードのメモリアクセス 0.00

17

優先度をつけたことによる性能の変化

lighttpd と tripwire を同時に動かす同じドメインと、別ドメイン

ポリシー lighttpd の優先度をあげる

lighttpd の性能は単独の時とほぼ同じ

別ドメインの場合でも lighttpd を優先できた

同じドメイン

別ドメイン0

50

100

150

200

250

300

lighttpd 単独

lighttpd を優先

100

万ア

クセ

スを

処理

する

のに

かか

る時

間 (

秒)

18

スケジューリング精度 円周率を計算する pi1 と pi2 を同時に起動

同じドメイン上 ポリシー

pi1 が動いている間は pi2 は実行しないスケジューラプロセスが

動く間隔を変える

間隔が長い精度低下

間隔が短いオーバーヘッド大精度は上がる 0 1 2 3 4 5 6

0

10

20

30

40

50

60

pi1 pi2

ポーリングの間隔 (秒 )

実行

時間

(秒

)

19

プロセススケジューリングの挙動 (1/2)

4 つのプロセスをスケジューリングドメイン U1 で 3 つ、ドメイン U2 で 1 つプロセスはすべて円周率を計算するプログラム

ポリシーPi1 の優先度を最低にする

pi1 をドメイン U の中で他にプロセスが動いていないときのみ動かす

Xen VMM

ドメイン U1 ドメイン U2

pi3 pi4

pi1

pi2

優先度最低20

プロセススケジューリングの挙動 (2/2)

ポリシーが実現できたグラフの各線が下のときはプロセスが止まっている上のときは動いているpi1 が 20秒付近で動いているのはバグ

0 10 20 30 40 50 60 70 80

デーモン等その他のプロセス

ドメイン U1 のプロセス pi3

ドメイン U2 のプロセス pi4

ドメイン U1 のプロセス pi2

優先度最低のプロセス pi1

経過時間 (秒 )

21

関連研究

Virtual Machine Introspection [NDSS'03, Garfinkel et al.] [SOSP'05, Joshi et al.]VMM からゲスト OS の状態を取得

Antfarm [USENIX'06, Jones et al.], Geiger [ASPLOS'06, Jones et al.]VMM からゲスト OS を仮定せずにプロセスやキャッ

シュの状態を取得する技術 FoxyTechnique [VEE'07, Yamada et al.]

VMM が仮想デバイスの振舞いを変更することで、ゲスト OS の振舞いを間接的に変更する技術

22

まとめと今後の課題 仮想マシンモニタによるプロセススケジューリ

ングを提案ゲスト OS のメモリを直接操作し、スケジューリング

を変更システム全体でプロセスに優先度を付けることが可

能実際にスケジューリングが行えることを確認

今後の課題 I/O バウンドなプロセスの制御CPU で実行中のプロセスの制御ゲスト OS が Windows の場合でのプロセス制御 23