

Virtual Machine Performance Demystified - wifelette
http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/

======
kmavm
I worked on VMware's virtual machine monitor from 2000 to earlier this year. I
overlapped with Michael Mullany, and his article is a fair recollection of our
efforts. The more technical crowd here might appreciate a few additional
thoughts.

1\. Everywhere he talks about "memory", he really means "privileged virtual
memory operations." Flushing the TLB, altering the virtual to physical
mappings, changing address spaces, etc. Ordinary loads and stores have always
been directly executed at native speed. He also merges "apache" (lots of
context switches) and "compile" (lots of process creation and page faults)
into the odd-sounding "apache compile").

2\. In my opinion, paravirtualization was first a hack, and only
retrospectively framed as a performance optimization. By hacking up Linux, the
Xen folks were able to get a viable system working much more easily than would
have been possible for unmodified kernels. The notional perf advantages of
this approach have, IMHO, not been convincingly shown, and RVI/EPT hardware
impressively raise the bar for ever demonstrating it.

3\. Although I worked on it, I would be very shy about claiming "hypervisor"
as a VMware invention. First, it is not an entirely accurate description of
ESX, which keeps a much more rigid separation of the "monitor" (responsible
for providing virtual CPUs, memory management hardware, and devices) from the
"vmkernel" (responsible for driving IO and keeping VMs out of one another's
way) than most people imagine when they hear the term "hypervisor". But most
importantly, I first remember hearing the term applied to kernels from the
first virtualization golden age, in the 1970's. We have stood on these giants'
shoulders enough without claiming their inventions for ourselves.

~~~
sokoloff
I interpreted "Apache compile" as "a compile of Apache ['s httpd server]".

~~~
kmavm
That's a reasonable interpretation, it just isn't my recollection of the
workloads we used for benchmarking. I remember running the actual httpd server
under synthetic loads, and compiling the Linux kernel make -j <bignum>.

------
grandalf
I think this article was in response to some of the issues that were mentioned
as a motivation for Github's move away from Engineyard... Specifically, Github
mentioned slow IO issues on virtual machines as a significant issue.

FWIW IO performance on Joyent is abysmal, and they supposedly use Sun's latest
virtualization technology.

It sounds like the problem is not with the technology but with how it's
managed... It's easy to partition memory and CPU resources, but not as easy to
partition IO resources.

I'm still waiting for virtual hosts that are paired with their own dedicated
solid state storage rather than sharing one hardware IO system or using slow
network storage.

~~~
hnmullany
Hi Grand -- this is michael. Yes this was to respond to some of the
perceptions out there that virtualization = slow. It's really not (at least
now, it isnt' - as long as you know what you're doing, some of the tech docs
to get the new hardware virtualization features working seem a bit daunting).
And on the other hand, there's no alternative to having enough hardware
capacity to meet your requirements. Virtualization can't make i/o capacity
appear from thin air.

------
wmf
This is about hypervisor performance. (Seeing the title and domain, at first I
expected it to be about Ruby VMs.)

