プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

[kernel watch没ネタ集] さよならVMI このエントリーをはてなブックマークに追加

VMwareの連中が、伝統的なVMIを使ったパラバーチャライゼーションより、EPT/NPTを使ったほうが速いのが分かったので、VMIは近々削除するよ。とのこと

おいおい、つい最近までVMwareのコード書き換え技術はァァァァァァ、世界イチィィィィィィ
URYYYYYYYYYYYYYY

とかいってたじゃんか。


Hi,

We ran a few experiments to compare performance of VMware's
paravirtualization technique (VMI) and hardware MMU technologies (HWMMU)
on VMware's hypervisor.

To give some background, VMI is VMware's paravirtualization
specification which tries to optimize CPU and MMU operations of the
guest operating system. For more information take a look at this
http://www.vmware.com/interfaces/paravirtualization.html

In most of the benchmarks, EPT/NPT (hwmmu) technologies are at par or
provide better performance compared to VMI.
The experiments included comparing performance across various micro and
real world like benchmarks.

Host configuration used for testing.
* Dell PowerEdge 2970
* 2 x quad-core AMD Opteron 2384 2.7GHz (Shanghai C2), RVI capable.
* 8 GB (4 x 2GB) memory, NUMA enabled
* 2 x 300GB RAID 0 storage
* 2 x embedded 1Gb NICs (Braodcom NetXtreme II BCM5708 1000Base-T)
* Running developement build of ESX.

The guest VM was a SLES 10 SP2 based VM for both the VMI and non-VMI
case. kernel version: 2.6.16.60-0.37_f594963d-vmipae.

Below is a short summary of performance results between HWMMU and VMI.
These results are averaged over 9 runs. The memory was sized at 512MB
per VCPU in all experiments.
For the ratio results comparing hwmmu technologies to vmi, higher than 1
means hwmmu is better than vmi.

compile workloads - 4-way : 1.02, i.e. about 2% better.
compile workloads - 8-way : 1.14, i,e. 14% better.
oracle swingbench - 4-way (small pages) : 1.34, i.e. 34% better.
oracle swingbench - 4-way (large pages) : 1.03, i.e. 3% better.
specjbb (large pages) : 0.99, i.e. 1% degradation.

Please note that specjbb is the worst case benchmark for hwmmu, due to
the higher TLB miss latency, so it's a good result that the worst case
benchmark has a degradation of only 1%.

VMware expects that these hardware virtualization features will be
ubiquitous by 2011.

Apart from the performance benefit, VMI was important for Linux on
VMware's platform, from timekeeping point of view, but with the tickless
kernels and TSC improvements that were done for the mainline tree, we
think VMI has outlived those requirements too.

In light of these results and availability of such hardware, we have
decided to stop supporting VMI in our future products.

Given this new development, I wanted to discuss how should we go about
retiring the VMI code from mainline Linux, i.e. the vmi_32.c and
vmiclock_32.c bits.

One of the options that I am contemplating is to drop the code from the
tip tree in this release cycle, and given that this should be a low risk
change we can remove it from Linus's tree later in the merge cycle.

Let me know your views on this or if you think we should do this some
other way.

Thanks,
Alok


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

関連記事


linux | 【2009-10-06(Tue) 11:26:08】 | Trackback:(0) | Comments:(6)
コメント
「VMwareのコード書き換え技術」って Binary Translation を指しているのでしょうか?

VMware は VT-x については Binary Translation の方が早いからと消極的ですが(でも
Intel CPU かつ x86_64 なOSの実行には仕方なく使ってますが)、shadow page table が
遅いのは重々承知ですから、RVI / EPT については積極採用してますよ。

http://www.vmware.com/pdf/RVI_performance.pdf
http://www.vmware.com/pdf/Perf_ESX_Intel-EPT-eval.pdf

なお、VMware Infrastructure 3.5 (ESX3.5)は昨年(2008)の4月のリリースで、何を
今更という感じがします。

あと、VMI には Binary Translation は関わってないですから(どっちかというと Xen
の準仮想化が流行したときの対応策の名残?)、「つい最近まで...言ってたじゃないか?」
と揶揄されるなら VMI を Linux に突っ込ませたときに言うべきだったかと思われます。

「RVI/EPTがあれば Binary Translation の方がやっぱり速かった、ので準仮想化ステ」
なのですから。

2009-10-06 火 10:35:57 | URL | shiro #- [ 編集]

ふむふむ。
ご指摘ありがとうございます。
VM系は全然うといので、コメントが半分以上理解できていませんが、じっくり勉強してみます。
2009-10-06 火 10:39:54 | URL | kosaki #- [ 編集]

VMware社は、ハードウェア仮想化はVT-xだけでは遅いので、EPTがないとダメと言う論文を出していました。(ページテーブルのハードウェア仮想化も必須と言うこと)
http://www.vmware.com/pdf/asplos235_adams.pdf
さて、仮想化の方法ですが、x86の場合、バイナリ変換、準仮想化、ハードウェアによる仮想化に分けられます。ここで、ハードウェア仮想化は、EPTが出て来るまで使えないと言う判断をした以上、それまでの対策を考える必要がありました。
そこで、同社の中で、バイナリ変換と、準仮想化(paravirt_ops)を比較して、準仮想化のほうが性能がよいと言う調査結果が出ていたのではと思います。当たり前ですが、仮想敵であるXenに性能面で負けるわけには行かない。
そして、本命のEPTが出てきたので、つなぎとしての準仮想化がフェードアウトすると言うのが真相では?

2009-10-13 火 08:33:34 | URL | sakaia #- [ 編集]

色々とご指摘ありがとうございます。今まで僕の中でVT-xとEPTが一部ごっちゃになっていたように思います。勉強になります。
2009-10-13 火 08:38:16 | URL | kosaki #- [ 編集]

ごっちゃというか、VT-xの中にEPTも入っていて、EPTはとっくの昔に実装済みだと勘違いしてた。Core i7からなのね。うむむ
2009-10-13 火 09:29:33 | URL | kosaki #- [ 編集]

すでに知っているとは思いますが

VT-x2 = VT-x + EPTその他になるようですね。
http://software.intel.com/en-us/forums/virtualization-software-development/topic/67802/
インテルのマーケティング用語は難しい...
2009-10-13 火 22:13:37 | URL | anonymous #- [ 編集]
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。