I think you need to compare Linux in a z/VM LPAR versus Linux Native, and determine if one has more i/o overhead than the other. I think the answer is going to be 'minimal'. As someone said, and I have observed, my CP%CPU runs at 2-3%.
As for MDC, I've been curious about that lately. About a week ago, I turned off mdc for a highly active volume, and it seemed to me that resp increased rapidly and markedly. I quickly turned it back on. So I tried just now, for fun. I took the highest activity volume in a large system, and turned MDC cache off. Here's the info at 5min intervals: I/O Rate Resp 127 3.0 MDC ON 86.5 6.5 MDC OFF 69.6 9.2 102 4.9 122 3.3 93 3.5 11.7 12.3 At that point its activity seemed to decrease. So I guess my test is shot. :) MA On Fri, Oct 31, 2008 at 8:49 AM, Rob van der Heij < [EMAIL PROTECTED]> wrote: > 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/ >
