Skip to main content

VMware does a performance study on AMD's RVI

Nice read, this doc.

In a native system the operating system maintains a mapping of logical page numbers (LPNs) to physical page numbers (PPNs) in page table structures. When a logical address is accessed, the hardware walks these page tables to determine the corresponding physical address. For faster memory access the x86 hardware caches the most recently used LPN->PPN mappings in its translation lookaside buffer (TLB).

In a virtualized system the guest operating system maintains page tables just like in a native system, but the VMM maintains an additional mapping of PPNs to machine page numbers (MPNs). In shadow paging the VMM maintains PPN->MPN mappings in its internal data structures and stores LPN->MPN mappings in shadow page tables that are exposed to the hardware. The most recently used LPN->MPN translations are cached in the hardware TLB. The VMM keeps these shadow page tables synchronized to the guest page tables. This synchronization introduces virtualization overhead when the guest updates its page tables.
Using RVI, the guest operating system continues to maintain LPN->PPN mappings in the guest page tables, but the VMM maintains PPN->MPN mappings in a second level of page tables, called nested page tables. When a logical address is accessed, the hardware walks the guest page tables as in the case of native execution, but for every PPN accessed during the guest page table walk, the hardware also walks the nested page tables to determine the corresponding MPN. This composite translation eliminates the need to maintain shadow page tables and synchronize them with the guest page tables. However the extra operation also increases the cost of a page walk, thereby impacting the performance of applications that stress the TLB. This cost can be
reduced by using large pages, thus reducing the stress on the TLB for applications with good spatial locality.

For optimal performance the ESX VMM and VMkernel aggressively try to use large pages for their own memory when RVI is used.

Get the Whitepaper here


Popular posts from this blog

DeepLearningTrucker Part 1

Avastu Blog is migrating to; 1st Jan 2009 live


I will send out emails personally to those who are using my link(s) on their sites.

Thanks much for your co-operation and hope you enjoy the new site and its cool new features :-)

Not like the site is unlive or something..on the contrary, its beginning to get a lot of attention already. Well most of the work is done, you don't have to worry about anything though:

What won't change

Links/Referrals: I will be redirecting the links (all links which you may have cross-posted) to - so you don't have to do anything in all your posts and links. Although, I would urge however that you do change the permalinks, especially on your blogs etc yourselfThis blog is not going away anywhere but within a few months, I will consider discontinuing its usage. I won't obviously do …

Cloud Security: Eliminate humans from the "Information Supply Chain on the Web"

My upcoming article, part - 3 data center predictions for 2009, has a slideshot talking about the transition from the current age to the cloud computing age to eventually the ideation age- the age where you will have clouds that will emote but they will have no internal employees.

Biggest management disasters occur because internal folks are making a mess of the playground.

Om's blog is carrying an article about Cloud security and it is rather direct but also makes a lot of sense:

I don’t believe that clouds themselves will cause the security breaches and data theft they anticipate; in many ways, clouds will result in better security. Here’s why: Fewer humans –Most computer breaches are the result of human error; only 20-40 percent stem from technical malfunctions. Cloud operators that want to be profitable take humans out of the loop whenever possible.Better tools – Clouds can afford high-end data protection and security monitoring tools, as well as the experts to run them. I trust…