Diagnose x250 will optimize all the I/O within a single request. It doesn't coalesce or optimize over multiple requests. Here is the usage note from the Programming Services Manual:
The I/O for the DASD blocks specified in the block I/O entries of the BELBK may not occur in the same order that they are listed. If the application requires that the DASD blocks or I/O data buffers be updated in a particular order, then that I/O request should be implemented with separate DIAGNOSE X'250' invocations. Steve Wilkins IBM VM Development z/VM I/O Strategy |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |"Gary M. Dennis" <gary.den...@mantissa.com> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |IBMVM@LISTSERV.UARK.EDU | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |03/30/2009 12:56 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: Diagnose x'250' / z/VM I/O scheduling | >--------------------------------------------------------------------------------------------------------------------------------------------------| Thank you. Let me clarify. The questions aren't about the device which, as you correctly observe, is now a software figment. All we see and can control on the System z end is the sub-channel. My thinking (and this may be entirely off base) is that scheduling a sub-channel request to write 25 blocks via a composite channel program is somehow better than 25 separate requests. Regards, Gary On 3/30/09 10:22 AM, "Schuh, Richard" <rsc...@visa.com> wrote: > The real question is, with today's disk arrays, what really is the > optimal order of the CCWs in the chain? What may seem logical to you, > who have apparently been around long enough to remember the days of each > disk being a physical unit with cylinders and tracks being arranged > sequentially, may not be optimal for disks that are striped across many > physical disks. > > The VSSI products, VPARS and VTAPE, use the BLOCKIO routines and, if I > am not mistaken, the VSSI code "optimizes" the channel programs by > sorting them into sequential order before the DIAG is issued. > > Regards, > Richard Schuh > > > >> -----Original Message----- >> From: The IBM z/VM Operating System >> [mailto:ib...@listserv.uark.edu] On Behalf Of Gary M. Dennis >> Sent: Monday, March 30, 2009 7:39 AM >> To: IBMVM@LISTSERV.UARK.EDU >> Subject: Diagnose x'250' / z/VM I/O scheduling >> >> Given >> >> A file pool consisting of >> 5 VDEV files on 5 separate real devices >> 2 cylinders per device >> 4096 block size >> >> >> When: >> >> a block chain is given Diag x'250' (async) for either >> read or write >> such that 4 blocks are written to or read from each track within >> the 5 files. >> >> Question(s): >> >> Does the 250 interface make any attempt to optimize I/O operations >> by constructing chained channel programs for single-track or >> consecutive-track multi-record writes/reads? >> >> If that is not the case, is such optimization achieved at >> a more basic >> level in z/VM real device I/O scheduling? >> >> Curiosity killed the.... >> >> In either of the above cases (that is if channel programs >> are chained >> based on intra-request I/O patterns), will either 250 or >> VM perform >> inter-request channel program chaining for multiple async requests >> targeting the same real device? >> >> Thanks >> >> --. .- .-. -.-- >> >> Gary Dennis >> >> 0 ...living between the zeroes... 0 >> > --. .- .-. -.-- Gary Dennis Mantissa Corporation 1121 Edenton Street Birmingham, Alabama 35242-9257 0 ... living between the zeroes... 0 p: 205.968-3942 m: 205.218-3937 f: 205.968.3932 gary.den...@mantissa.com http://www.mantissa.com http://www.idovos.com