The comparison is already complicated because of different terminology. For example what we consider the "overhead of I/O" Is that in CPU resources, memory or I/O resources? A Linux system for example use a cache to avoid I/O, but that means there is "memory overhead" for I/O. And when the page cache is very large, there is also CPU overhead in managing that cache. Depending on the cache hit ratio and the disk response time, the overhead may result in faster response. And who would measure that on VMware?
When talking to people from the "other side" it seems that "I/O overhead" is sometimes the measured throughput of an (assumed) I/O bound application, running either on VMware or native. To me such an interpretation has more questions than answers. But VM people tend to look at the T/V ratio of a virtual machine running such an application. That's not entirely fair because it also includes the cost of security, performance instrumentation, error recovery, etc. If a virtual machine wants to do I/O it may require paging to make room for the new data - is that I/O overhead? In general, I don't think that the difference in I/O performance is a motivation to run in LPAR rather than in a virtual machine. Before 5.2 we had the 2G issues that affected many installations. z/VM 5.3 addressed some more of these issues. One factor I do know about is MDC: many new workload does not exploit it as much as we used to do, so it sometimes good to consider not spending the resources on that. One of the factors that influences virtual machine I/O is the extra latency that comes with running multiple virtual machines. While this does not impact the overall throughput of the configuration, it does affect the maximum single thread throughput. That's what makes benchmarking complicated in this environment. QDIO (as used for OSA devices and FCP) is meant to address this latency issue. Under proper conditions this allows the channel to drive the I/O operations without waiting for the virtual machine to be dispatched and issue the next SSCH. This does have its price though, the CPU usage is higher than with ECKD I/O, so if you're CPU constrained the I/O might become slower. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
