結果の評価
(1) CPU-bound benchmarks● 49のベンチマークでマルチスレッドベンチマークを実行
● TLBミス処理にサイクル全体の5%以上を費やしたのは6つのプログラムのみ
● 物理マシンと仮想マシンでパフォーマンスが二倍以上違うのはparsec.dedupのみ
○ dedupではTLBミス回数の増加により仮想実行のオーバーヘッドが大きくなる
○
[Appendix] dedup
と
page sharingPage Sharing
● ハイパーバイザがVMのRAM内に同一のページがないかチェックし、存在すればホ ストの同一の物理メモリに書き込む
● persec.dedupはこの同一の内容のページを排除する(Memory Deduplication) を積極的に行うベンチマークであるため、おそらくpage splinterringが頻繁に発生 するため、特に仮想マシン上でパフォーマンスが落ちる
VM2 RAM
VM1 RAM VM3 RAM Memory Hardware RAM
Deduplication を行う
結果の評価
(1) CPU-bound benchmarksハイパーバイザによるマッピングを行わない場合
● ハイパーバイザでの2MBページマッピング(gPA→ hPA)を行わない場合、ページ テーブルのサイズが大きくなり、EPT-level Walkが長くなってしまう
● いくつかのベンチマークでは物理マシンと数倍以上のパフォーマンス差が生じる
マッピングを行わなった場合の平 均
マッピングを行わなかった場合 の平均
mcfはマッピングを行わない場合、
4.3倍の%サイクル時間が要する ようになった
結果の評価
(2) Database Benchmark Analysis● TPC-Cベンチマーク(トランザクション処理とデータベースのベンチマーク)
を行い、現実世界での巨大なデータベースでどうパフォームするか
○ 小さなデータセットではよりキャッシュの利用度が上がりやすい
● TLBミス処理に当てられる時間(表のWALK_DURATION)はネイティブマ シンで19.6%, 仮想マシンで15.4%
○ これはEPT Walk Cycleに当てられる時間の増加(5.4%)により説明さ れる
結果の評価
(2) VMmark Analysis● 単一の仮想マシンだけでなく、複数の仮想マシンでベンチマーク実験
● VMmark = 産業レベルの複数仮想マシンサーバのためのベンチマーク
● 処理時間全体の12.3%がTLBミス処理に費やされ、その4.3%がEPT Walkによって説明可能
● TLBミス処理全体に占めるEPT Walkの割合の小ささを考えると、多くの場 合はL1, L2, L3キャッシュのいずれかにヒットしたのではないかと考えられ る。
● TPC-Cと比較するとPage Splinteringの有無によるパフォーマンスのさ差 異が大きい
(補足)
page splinteringとは
Page Splintering
● 仮想化ソフトウェアはしばしば大きなページ(2MBなど)をより 小さなチャンク(4KB程度)に分割
● 利点
○ Page Sharing(前述)が可能
○ 参照の局所性(メモリ)が向上できる
○ Working set samplingによるパフォーマンス向上
● 欠点
○ アドレス変換のオーバーヘッドを増加させる
結果の評価
(2) Vmmarkでの
page splinteringの効果
● TPC-Cではsamplingの有無によるパフォーマンスの差は小さい
● VMMarkでは2GBの小さなRAMをもつVMを複数使用するため、
working set samplingの効果が大きくなる
サンプリングを無くした ことでパフォーマンス が-33%