David Boyes wrote: >My original point was to break up the big minidisks or full >volumes into smaller pieces that you can move around to avoid the >problem of blocking on a single I/O to a device. > >Since VM PAV support is still not in the cards, the technique does help >simulate the same effect, and thus, is an improvement over fullpack >minidisks or dedicated volumes.
But this does not simulate the same effect. It is analogous to saying that you can help a CPU-constrained task by defining more virtual CPUs to the guest than the machine has physical CPUs -- this just does not work. If CP accepts a request from Linux's queues only to put it onto its own queues, this helps nobody. In fact, if the request had remained on Linux's request queue Linux would have been able to better combine it with subsequent requests, and so reduce the total number of requests and overhead they incur. In our experience, a Linux system that has any nontrivial I/O load (database servers etc.) will usually be constrained by the throughput of the (physical) channel, in particular if you're using ESCON. The only thing that helps is to make multiple *physical* channels available to Linux; in the situation the original poster described I'd recommend to dedicate multiple DASD devices to the guest (the number of devices at least as big as the number of physical channels that go to the storage subsystem), and use LVM with appropriate striping over those devices. As Barton mentioned, you should also make sure that the devices are spread out over the internal paths on the storage subsystem; see e.g. Klaus Bergmann's SHARE presentation for details on how to do so. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
