OS 論文購読チャレンジ

仮想マシンのメモリ管理浅井明里 王力捷

アウトライン

1. 仮想記憶の基本原理

2. 仮想マシンにおける仮想記憶の仕組み

3. Performance Implications of Extended Page tabls on Virtualized x86 processors”紹介a. この論文の概要

b. 背景

c. 実験のセットアップ

d. Microbenchmark実験の結果及び分析

e. Benchmark実験の結果及び分析

f. 評価

g. 結論

仮想記憶の基本原理

仮想記憶

● 磁気ディスク装置と主記憶装置を組み合わせて、コンピュータ

に実装されている主記憶の容量以上の仮想の主記憶領域を

提供する

● その時点で必要な部分だけを実際の主記憶に、そうでない部

分を磁気ディスク装置（またはSSD）に配置

● 入れ替えの単位としてプログラムの機能単位のまとまりで分

けるセグメント方式と固定長のページ方式がある

仮想記憶とは

今回は主にこっちを前提に話をします

ページテーブル

● 仮想アドレスと物理アドレスのマッピングを格納する

○ 仮想アドレス = プロセスごとに割り当て

○ 物理アドレス = システム全体でRAMなどを配置

● ページテーブルは仮想アドレスを受け取り、ページテーブル上

で仮想ページアドレスを参照し、対応する物理ページアドレス

があればそれを返す

● このとき、ページが主記憶に入っていない(有効ビットが0の時)はページフォールトを起こす。

仮想記憶の構成 (1) ページテーブル

ページング

● 固定サイズのページを単位に仮想アドレスから物理アドレスの変換を行う

仮想記憶機構におけるページングとは

仮想ページ番号(VPN) ページ内オフセット

物理ページ番号(PPN) ページ内オフセット

仮想ページ番号から物理ページ番号への変換を行う

ページサイズがpビット、アドレス全体がmビットの場合

m - p ビット p ビット

仮想アドレス

物理アドレス

変換

有効 書き込み可

対応する物理ページ番号

0 0/1 2次記憶上のアドレス

1 0/1 物理ページ番号

物理ページ番号 ページ内オフセット

仮想ページ番号 ページ内オフセット

PTE(ページテーブルエントリ )

ページテーブルによる仮想/物理アドレス変換

仮想アドレス

物理アドレス

変換

ページテーブル

ページテーブルの問題点

● ページテーブルはメモリに置かれる○ 1GBデータのために1MBのページテーブルが必要

● 頻繁にメモリアクセスするとレイテンシーが大きくなる

1GB(2^30B)

2^30 / 2^12 = 2^18個

メモリ ページ

4KB(2^12B)

ページテーブル

4Byte

4Byte

4Byte

4Byte

2^18 * 2^ 2 = 2^20 (1MB)

仮想記憶の構成 (2) TLB

TLB (Translation Lookaside Buffer)

○ メモリ管理ユニット内のページテーブルのキャッシュ

○ 直前に使用されたページテーブルエントリが格納

○ ページテーブルが読み込まれるごとにTLBにエントリが

CPUにより格納される(Hardware Manage TLB)○ TLBに対応する物理アドレスがないとTLBミス

○ TLBミスをするとページウォーク(ページテーブルから該当

するエントリを読み込む)を行う

有効 書き込み可

対応する物理ページアドレス

0 0/1 2次記憶上のアドレス

1 0/1 物理ページアドレス

物理ページ番号 ページ内オフセット

仮想ページ番号 ページ内オフセット

TLBによる仮想/物理アドレス変換とTLBミス

HIT!!

ページテーブル

TLB

ミス

仮想マシンにおける仮想記憶

仮想マシンの大まかな構成

● VMM（Virtual Machine Monitor）○ 仮想マシンとホストマシンをつなぐソフトウェア

○ またの名をハイパーバイザー（Hypervisor）と言う。

● Intel IA-32アーキテクチャ○ よく使われるIntel x86アーキテクチャのことだと思って大丈夫です。

仮想マシンにおける仮想記憶

● 各仮想マシンはそれぞれ仮想ページテーブルを持つ

○ 仮想ページテーブルで仮想マシンの仮想アドレスから仮想

マシンの実アドレスに変換する

○ 仮想マシンの実アドレスと物理マシンの物理アドレスは異

なる

● VMM上で仮想マシンの実メモリと物理マシンの物理メモリへ

のマッピング行われている(real-to-physical mapping)● 複数のVMの仮想アドレスが一つの物理メモリをさしてしまう状

況を回避する

ゲスト仮想マシンのメモリマッピング

仮想マシンの仮想メモリ(VMごとに保有)

1000

2000

仮想マシンの実メモリ(VMごとに保有)

1500

5000

システムの物理メモリ(ネイティブマシンのみ )

2000

2500

仮想ページ 実ページ

1000 1500

2000 5000

実ページ 物理ページ

1500 2000

5000 2500

VMMeach VM

なぜ二段階のアドレスマッピングが必要か

仮想アドレス 実アドレス

500 1000

1000 2500

1300 500

仮想アドレス 実アドレス

300 1000

500 2300

1800 700

VM1のページテーブル

VM2のページテーブル

VM1の仮想メモリ

VM2の仮想メモリ

物理マシンの物理メモリ

複数の仮想メモリのマップ先が物理メモリ上でぶつかってしまうかも？

“Performance Implications of Extended Page tabls on Virtualized x86 processors”の紹介

1. 概要

この論文の概要

● 仮想マシン上で仮想メモリを実現するのはコストが大きい● 仮想マシンではTLBミスのコストが物理マシンより大きく増加● 2D ページウォークにより、物理マシンの 6倍のページテーブル参照が必

要になる → コストは6倍● これまでの研究はTLBミスのコスト削減フォーカス

● 仮想マシン上での2D TLBミスのコストを様々なベンチマークで調査● [4] Extended Page Tableの実際の性能調査● [5] TLBミスでサイクル全体の5%以上の時間を消費したベンチマークはか

なり少数派● [5] 仮想マシンで2倍以上差が出たのは全ベンチマーク中 1つのみ

● 最新のCPU(modern x86 processros)ではより大きなTLBと階層的なページ構造キャッシュにより、物理マシンと仮想マシンでのパフォーマンスの差異を大きく削減

● 実際には仮想化によるTLBミス処理のオーバーヘッドは TLBミス処理全体のごくわずかな割合

Conclusion

ExperimentEvaluation

IntroBackground

あらすじ

● 仮想マシンのメモリ管理ってめんどくさそうだしめっちゃ時間かかると思われてい

る。

● 実際に、バーチャルマシンでのメモリ読み込みはネイティブマシンの最大6倍かか

るって研究があるが、、、

● 今の新しいCPUとソフトウェア群を使うとそんなことない！● ちなみに、ページサイズを大きくすると、仮想マシンでメモリを読んでも物理マシン

でメモリを読む場合と比べて3%~5%しか時間が変わらない

（参考）VMのメモリ読み込みがホストより6倍時間がかかると言っていた論文について

J. Buell, D. Hecht, J. Heo, K. Saladi, and H. R. Taheri, Methodology for Performance Analysis of VMware vSphere under Tier-1 Applications, in VMware Technical Journal, 2013.

● CPUはNehalemアーキテクチャ←少し古い

● vSphere 5.1 というVMwareの仮想化システムでテストした。←少し古い

○ PMU (Performance Monitoring Units)を使ってハードウェア的に計測。

● OLTP（リアルタイムのトランザクション処理）では、処理数を全体で見ると、ネイティ

ブシステムの79%とそこそこある。

○ Hadoopも同じ傾向。

● 一方、ページウォークについて見ると、

○ OLTPでは、サイクル数が約3倍、

○ Hadoopでは、サイクル数が約4～5.5倍。

○ どうやら、L1キャッシュがゲストとホストで競合するらしい。

2. 背景

2.1.物理マシンでのアドレス変換

2.2. 仮想記憶の仮想化

ハードウェアによる仮想MMU

2.3. 2-Dページウォークの短縮

2.4. TLBキャッシュとページサイズ

（背景知識）x86 Processorのメモリ管理の構造

● x86 (32ビット)○ 仮想アドレス空間32ビット、物理アドレス空間32ビット

■ つまり、仮想記憶・物理記憶ともに最大232 ビット＝約4 GB○ ページサイズは4 KB (12ビット）もしくは 4 MB（22ビット）

■ 構造は以下の通り

10 bit 10 bit 12 bit

L2ページ番号 L1ページ番号 ページ内オフセット（ページ本体）

10 bit 22 bit

L2ページ番号 ページ内オフセット（ページ本体）

もしくは

有効 書き込み可

対応する物理ページアドレス

0 0/1 2次記憶上のアドレス

1 0/1 物理ページアドレス

物理ページ番号 ページ内オフセット

仮想ページ番号 ページ内オフセット

PTE(ページテーブルエントリ )

（再掲）ページテーブルによる仮想/物理アドレス変換

仮想アドレス

物理アドレス

変換

ページテーブル

（背景知識）x86 Processorのメモリ管理の構造

● x86-64 (64ビット)○ 仮想アドレス空間48ビット、物理アドレス空間52ビット

■ つまり、仮想記憶最大約256 TB、物理記憶最大約4 PB○ ページサイズは4 KB（12 ビット）もしくは 2 MB（21 ビット）

■ 構造は以下の通り

9 bit 9 bit 9 bit 9 bit 12 bit

L4ページ番号 L3ページ番号 L2ページ番号 L1ページ番号 ページ内オフセット（ページ本体）

9 bit 9 bit 9 bit 21 bit

L4ページ番号 L3ページ番号 L2ページ番号 ページ内オフセット（ページ本体）

もしくは

（背景知識）多段ページテーブル

…

…

物理ページ番号

…

物理ページ番号 オフセット

L2仮想ページ番号 L1仮想ページ番号 オフセット

PTE(ページテーブルエントリ )

仮想アドレス

物理アドレス

変換

ページテーブル

ページテーブル番号

…

…

…

PDE(ページディレクトリエントリ )

ページディレクトリテーブル

物理アドレスCR3レジスタ

物理アドレス

（背景知識）多段ページテーブル

…

…

物理ページ番号

…

物理ページ番号 オフセット

L2仮想ページ番号 L1仮想ページ番号 オフセット仮想アドレス

物理アドレス

変換

ページテーブル

ページテーブル番号

…

…

…

ページディレクトリテーブル

CR3レジスタ

この一連の流れを

ページウォークという

（背景知識）4段のページテーブルなら…

…

…

エントリ

…

…

エントリ

…

…

…

…

�

…

エントリ

…

…

…

�

…

エントリ

…

…

…

�

L4ページテーブル

L3 L2 L1

PDE(ページディレクトリエントリ )

PTE(ページテーブルエントリ )

ページ

ページ

CR3レジスタ

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

ページウォーク本体（ページテーブル）

ページテーブルのキャッシュ

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

もしTLBで見つかれば直接物理アドレスが分かる

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

ページウォーク本体

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

ページウォーク本体

L2キャッシュL2ページテーブルのキャッシュ。仮想アドレスからL1ページテーブルの位置を見つける。

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

L2キャッシュL2ページテーブルのキャッシュ。仮想アドレスからL1ページテーブルの位置を検索する。

ページウォーク本体L2キャッシュの中で見つかれば、ページウォークは、L1ページテーブル中だけでよい。

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

ページウォーク本体

L3キャッシュ仮想アドレスからL2ページテーブルの位置を検索する。

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

ページウォーク本体L2キャッシュの中で見つかるよりもページテーブルを引く回数が多い。（それでもキャッシュがないよりまし）

L3キャッシュ仮想アドレスからL2ページテーブルの位置を検索する。

2.1. ネイティブマシン（x86-64）でのアドレス変換

仮想アドレス （VA）

物理アドレス （PA）

ページウォーク本体

どのキャッシュでも見つからなかった場合

ページウォーク全体を行う。

2.2. 仮想記憶の仮想化／2.3. ハードウェアによる仮想MMU

● 仮想マシン上の仮想記憶も透過的に使える方がうれしい

→仮想マシン上のページテーブルがうまくネイティブマシンの

物理メモリに接続できればよい

● 方法

○ ソフトウェア：Shadow Tableなど

○ ハードウェア：Intel EPT

ここ！

今回は主にEPT

Intel EPT (Extended Page Tables)

● ハードウェアによる仮想マシンのメモリマッピング支援

● 前述のgVA（ゲスト仮想アドレス）→ gPA（ゲスト実アドレス） → hPA（ホスト物理アドレス）への二段階のアドレス変換を一

度に行う仕組み

● 似た意味の名称

○ SLAT (Second Level Address Translation)○ 2-D Page Walk（どちらかというとメモリ探索の仕組み）

○ Nested Paging

Intel EPT (Extended Page Tables)

Intel EPT (Extended Page Tables)2-D

ゲストレベルページウォーク

EPT ページウォーク

ホスト物理アドレス

ゲスト物理アドレス

Intel EPT の仮想マシン側

ゲスト仮想アドレス

（gVA） ホスト物理アドレス

（hPA）

● 簡略化して、仮想マシン側から見ると…

CPU

仮想ページテーブル

ホスト TLB

ホスト L2キャッシュ

ゲスト CR3レジスタ

ホスト L3キャッシュ

ホスト L4キャッシュ

ホスト CR3

ホスト L4 PDT

ホスト L3 PDT

ホスト L2 PDT

ホスト L1 PET

Intel EPT のネイティブマシン側

ゲスト物理アドレス

ホスト物理アドレス

仮想ページテーブル

普通のx86のページウォーク

Intel EPTの良いところ

● 処理をハードウェアが行っているので早い

○ キャッシュなどを適切に使えるのが良い

● 処理の構造がゲスト側とホスト側でほとんど同じ

（参考）VirtualBoxの設定画面

（参考）VirtualBoxの設定画面

このチェックボックスを外すと結構もっさりします。

2.3. 2-Dページウォークの短縮

● TLBとキャッシュの使用により、2-Dページウォークが短縮でき

る

○ ゲストのTLBにより、gVA(ゲストの仮想アドレス)とhPA(ホストの物理アドレス)がそのまま変換できる

○ ゲストでのページ構造キャッシュがgVAからhPAの変換を

保持していることで、ゲストレベルでのウォークの量を減ら

すことができ、結果としてホストでのウォークの量も減らす

○ ホストレベルでのウォーク自体もウォークの量を減らす

ページ構造キャッシュをもつ

2.3. 2-Dページウォークの短縮

仮想アドレス （VA）

物理アドレス （PA）

ページウォーク本体スキップ

2.3. ページ粒度の拡大とページウォーク削減

● また、ページサイズを大きくすることでページウォークの量を減

らせる

○ ページサイズ4 KBの場合→ページテーブルを引く回数は

24回○ ページサイズ2 MBの場合→ページテーブルを引く回数は

15回

2.3. ページ粒度の拡大とページウォーク削減

○ ゲスト・ホストともにページサイズ4 KBの場合

→ページテーブルを引く回数は24回

gVA→hPAの変換：4ロード×5回=20回

gPTを引く回数：4回

計：24回

（引用）：

Large Pages and Lightweight Memory Management in Virtualized Environments: Can You Have it Both Ways?

2.3. ページ粒度の拡大とページウォーク削減

○ ゲスト・ホストともにページサイズ2 MBの場合

→ページテーブルを引く回数は15回

ゲスト・ホストともに中間で引くページの数が一つ減る

gVA→hPAの変換：3ロード×4回=12回

gPTを引く回数：3回

計：15回

2.4. TLBキャッシュとページサイズ

● 仮想化された環境において、ゲスト、ホスト共にページサイズ

を2MBマッピングするとhPAが連続するため、hTLBでのエント

リを一つにまとめることができる

4KBでマップされたエントリについてはhPAで非連続になってしまう

gPAが2MBでマップされるとhPAも連続してマップされることになる

2MBマッピングの効果

012

1024

512...

2MB

2MB

2MB

2MB

...

hPAgPAgVA

0

1

page0の先頭へのgPAとpage1へのgPAは4KBずつずれる

hPAを一つにまとめると、PTEは一つですむ

2^21/2^12= 2^9 = 512

3. 実験のセットアップ

3. 実験のセットアップ

● 実験の目的 ○ 様々なワークロードの中で仮想化されたアドレス変換に関する調査を

行うこと

○ 実世界でのアプリケーションも視野に様々なサイズのデータをメモリに

マッピングして実験を行った

● 実験に用いたマシン ■ Dell PowerEdge R730 with two 2.30GHz 18-core Intel

Processors Xeon E5-2699 v3 (Haswell-EP) and 512GB of memory● VMware ESXi vSphere Release 6.0, with a single guest

(RHEL 7.1) using 64 virtual CPUs and 475GB of memoryで稼働

■ two E5-2687W v3 (Haswell-EP) processors with 10 cores per processor

4. Microbench

4.0 TLBミスごとのページウォークに

かかる消費サイクル数

4.1.1. 仮想マシンのEPT walkの回数

4.1.2 仮想マシンのEPT loadの回数

4.1.3 メモリ遅延時間

4. Microbenchmarkの概要

0. 仮想マシン・ネイティブマシンのページサイズの条件を変えな

がらTLBミスごとのページウォークにかかる消費サイクル数を

調べた

1. ネイティブマシンのページサイズを2MBに揃えて、仮想マシン

のページサイズを変えながらTLBミスごとの

1.1. EPT walkの回数

1.2. EPT loadの回数

1.3. メモリ遅延時間

を調べた

4. Microbenchmark概要

0. 仮想マシン・ネイティブマシンのページサイズの条件を変えな

がらTLBミスごとのページウォークにかかる消費サイクル数を

調べた

1. ネイティブマシンのページサイズを2MBに揃えて、仮想マシン

のページサイズを変えながらTLBミスごとの

1.1. EPT walkの回数

1.2. EPT loadの回数

1.3. メモリ遅延時間

を調べた

4.0. TLBミスごとのページウォークにかかる消費サイクル数

（注）：ラベルは、（環境） -（仮想マシンのページサイズ） -（ネイティブマシンのページサイズ）

ホストページサイズ2 MB

ホストページサイズ4 KB

実環境

ゲストページサイズ2 MB

ゲストページサイズ4 KB ホストの消費サイクル数

ゲストの消費サイクル数

4.0. TLBミスごとのページウォークにかかる消費サイクル数

（注）：ラベルは、（環境） -（仮想マシンのページサイズ） -（ネイティブマシンのページサイズ）

ホストページサイズ2 MB

ホストページサイズ4 KB

実環境

ゲストページサイズ2 MB

ゲストページサイズ4 KB ホストの消費サイクル数

ゲストの消費サイクル数

ホストのページサイズを大きくすると速くなる

ゲストのページサイズを大きくすると速くなる

4. Microbenchmark

0. 仮想マシン・ネイティブマシンのページサイズの条件を変えな

がらTLBミスごとのページウォークにかかる消費サイクル数を

調べた

1. ネイティブマシンのページサイズを2MBに揃えて、仮想マシン

のページサイズを変えながらTLBミスごとの

1.1. EPTウォークの回数

1.2. EPT ロードの回数

1.3. メモリ遅延時間

を調べた

1. EPTウォーク

2. EPTロード

3. メモリ遅延時間

メインメモリ

EPTウォークとEPTロードの違い

● EPT ウォーク

○ ゲストから見た、ページテーブルを1段引く処理

○ また、ホストで一回仮想マシンの実アドレスから物理マシンの物理アドレスに

変換する処理

● EPTロード

○ ホスト（CPU）から見た、ページテーブルを1段引く処理

4.1.1. TLBミスごとのEPTウォークの回数

1

1.5

● 理論的には、ページサイズ2MBの場合のほうがページテーブルが1段階少ない分

ページサイズ4KBの場合と比べてEPTウォークが1回少なくなるはず

● マッピングしたデータが4GB以外の場合、EPTウォークの回数の差は約1回○ ページ数が小さい場合は、キャッシュでヒットする確率が高くなるので回数が

少なくなりがち（たぶん）

ゲストページサイズ4 KB

ゲストページサイズ2 MB

（ホストページサイズ2 MB）

4.1.2. TLBミスごとのEPTロードの回数

● EPTロードの回数もページサイズが2 MBの場合の方が4 KBの場合よりも1.0回以

上少ない。

1

1.8

ゲストページサイズ2 MB

ゲストページサイズ4 KB

（ホストページサイズ2 MB）

4.1.3. 命令ごとのデータ読み込み元

● データ自体に関するお話

● メモリ遅延時間は、データを記憶機構のどこから取得するのか

に影響している

○ 特に、データがL3データキャッシュにあるかメインメモリに

あるかで特に変わる※

● この計測ではどれぐらいのデータがL3データキャッシュでヒッ

トして、どれだけのデータがメインメモリでヒットするかをカウン

トした。

○ が、どうやらメインメモリをヒットした回数が少なめにカウン

トされているらしい…

※ここで言う「L3データキャッシュ」はいままで述べてきた「 L3ページテーブルキャッシュ」と

は別物

（参考知識）データキャッシュ

データ

メインメモリL(n)キャッシュL(n-1)キャッシュ

よく使うデータ

4.1.3. 命令ごとのデータ読み込み元

● ゲストのページサイズが小さいとエントリの数が増加する

● L3データキャッシュ・メインメモリが呼ばれる回数が大きく増える

（ゲスト側）

ゲストページサイズ4 KB

ゲストページサイズ2 MB

ゲストページサイズが大きいほど、L1, L2キャッシュまでにヒットする可能性が上昇する

4.1.3. 命令ごとのデータ読み込み元

● ゲストのページサイズはL3データキャッシュ以降の呼び出し回数にほとんど影響を

与えない

（ホスト側）

ゲストページサイズ4 KB

ゲストページサイズ2 MB

5. Benchmark

5.1. マルチスレッドベンチマーク実験

及びネイティブ仮想環境比較

5.2. データベースベンチマーク実験

5.2.1 Page Splinterrとは

5.3. VMmarkベンチマーク分析

5.3.1 working time sampling

結果の評価 (1) CPU-bound benchmarks

● 49のベンチマークでマルチスレッドベンチマークを実行

● TLBミス処理にサイクル全体の5%以上を費やしたのは6つのプログラムのみ

● 物理マシンと仮想マシンでパフォーマンスが二倍以上違うのはparsec.dedupのみ○ dedupではTLBミス回数の増加により仮想実行のオーバーヘッドが大きくなる

○

[Appendix] dedupとpage sharing

Page Sharing

● ハイパーバイザがVMのRAM内に同一のページがないかチェックし、存在すればホ

ストの同一の物理メモリに書き込む

● persec.dedupはこの同一の内容のページを排除する(Memory Deduplication)を積極的に行うベンチマークであるため、おそらくpage splinterringが頻繁に発生

するため、特に仮想マシン上でパフォーマンスが落ちる

VM2 RAMVM1 RAM VM3 RAM Hardware RAMMemory 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%

7. Conclusion

7. Conclusion

● 仮想環境におけるTLBミスの影響は世間一般で考えられているほど深刻ではない

● 最悪のケースではEPTウォークのコストは大きいが、より大きなTLBと階層的な

ページ階層キャッシュをもつモダンなプロセッサーはTLBミスのコストを削減する

● 一方で、やはり仮想システムにおいて、アドレス変換コストを低く抑えるためにTLBミスを可能な限り回避する必要がある

Finish!

8. 感想

8. 感想

● VMwareのvSphereというソフトウェアに隠れてしまっている部分をあって困った。

● それぞれの実験のベンチマークが何をするためのものなのかについての詳細な説

明が論文中にないので調べに行くのが少し大変だった(特にBenchmark)○ e.g. parsec_benchmark

● 仮想マシン上の2D Walkの動き方や、ページサイズとPTBサイズ及びアドレス変換

コストの関係について当初この論文だけでは理解できず、他のいくつかの論文を参

考にする必要があった

● Page Splinterとページサイズについての話はもう少し別の論文も参考にもっとまと

めてもよかった

Thank you for Listening!!

田浦先生ありがとうございました

参考資料

● Accelerating Two-Dimensional Page Walks for Virtualized Systems● Large Pages and Lightweight Memory Management in Virtualized

Environments: Can You Have it Both Ways? ● Tradeoffs in Supporting Two Page Sizes● コンピュータアーキテクチャ (電子情報通信レクチャーシリーズ)