On Thu, Feb 19, 2009 at 4:36 AM, Ivan Warren <[email protected]> wrote:
> Now about Diag 250.. What's the gain ? > > performance ? let's face it.. CP has become very efficient at > translating VM issued CCWs to real CCWs over the past 40 years or so.. > When dealing with a 1.2 Mips 4341 Model 2, CP Assisted I/Os made sense.. > now, With a 90,000+ MIPS z10.. well.. > > And if you're using Diag 250 so that you don't have to translate a block > number to CCCCHHRR, you're just shifting the work from the Virtual > Machine user mode to CP supervisor mode. Dear Ivan, While the speed of our CPUs has increased, the amount of data we work with has also grown seriously. It would be interesting to see whether the percentage of capacity spent on CCW translation has changed in those 40 years... You know there is more to it. The advantage of a high level interface is that the guest does not require the most intimate details of the (hardware) protocol to be emulated. Instead, guest and hipervisor can focus on getting the work done in the most efficient way. Unfortunately the "chicken & egg" applies: the Linux folks are less eager to exploit high level interfaces because they also need to get the hardware interface to work, and the VM people don't invest much energy because Linux is using the emulation hardware interfaces anyway... Considering most things, it probably would be wiser for z/VM to provide the function of Diag250 in the form of "virtual FCP" devices. Since the interface is not documented, I can't tell whether the designers had enough imagination that CP could implement this in an efficient manner. And I understand that the s390 port of Linux is limited in what you can exploit, because of the fact that much of the design stuff is in the common Linux kernel code. For example, z/VM could really enjoy a mechanism where Linux tells the hipervisor that a disk block is free. This would work for VDISK swapping and to purge data from MDC. But the block device does not have such an API yet, so nothing in Linux calls that function. Another area is the way Linux blocks the I/O. The internals build entirely on doing all read or all write operations, but no mix. And a single Linux I/O operation is all consecutive blocks. The Diag250 does not have that requirement, so if Linux could exploit it, we would do away with all I/O scheduling stuff. One of the neat things about Diag250 is that it supports a fast-path when the data is in MDC (the I/O complete is returned immediately, skipping the entire process of reflecting an interrupt later). Linux supports that in that you also get a quick route back there. I've even done Linux multi-pathing on that to exploit it like PAV does. But I have been pushing this less lately after I was disappointed about some low-hanging fruit that z/VM was unable to pick... We can certainly measure a difference in CP overhead between Diag250 doing 4K pages and a virtual FBA doing channel programs with 512-byte blocks. But as you say, with modern CPUs you need to do a lot of I/O to make it worth the trouble. And as long as it involves actual disk I/O, you may not be able to approach I/O rates where you care. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
