My CMG 2006 paper on virtualization was recently blogged at HP Labs in the context of hyperthreading being considered harmful to processor performance. The paper actually provides a general unified framework in which to understand hyperthreading, hypervisors (e.g., VMware, and Xen), and hyperservices (e.g., P2P virtual networks like
BitTorrent); the latter being an outgrowth of something I wrote in response to an online analysis of Gnutella.
The VM-spectrum concept is based on my observations that: (i) disparate types of virtual machines lie on a discrete spectrum bounded by hyperthreading at one extreme and hyperservices at the other, and (ii) poll-based scheduling is the common architectural element in most VM implementations. The associated polling frequency (from GHz to μHz) positions each VM into a region of the VM-spectrum. Several case studies are analyzed to illustrate how this framework could make VMs more visible to performance management tools.
A couple of questions:
ReplyDelete* What's the problem with just ignoring the performance of a VM? What do I, or any vendor, gain from gathering and using these stats?
* Does this taxonomy have practical applications?
* Why won't "just add more hardware" work? After all, servers, disk and bandwidth are very cheap.
[ Actually, that's 3 questions ;) ]
ReplyDeleteYou're always free to ignore performance. Any VM comes with overheads that depend significantly on the type of applications you are running. But you may still choose to implement your apps on say a VMM for reasons other than performance, e.g., server consolidation, internal politics, etc.
Whether or not my VM spectrum paradigm is practical or not will have to be judged by others. Recognizing that such a classification scheme is possible is already a practical step in the right direction, IMHO.
As a general proposition, hardware is cheap. However, if your application is single-threaded (rather than hyperthreaded), a truck-load of cheap PCs won't buy you one iota of performance.