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
