Only a subset of privileged instructions require intervention from VM
hence huge overhead for 3'th level VSE.  MOVE kind instructions for
example would ran at native speed, no matter how deed the SIE
instruction is nested.
Driving IO is the most obvious area that require VM intervention.
Avoiding IO will save CPU cycles that then can be used for something
else.  So as Geert and I suggest: buffer as much as possible in VSE.
the IOs VSE will still issue will be seen by the second level VM, if
it can find the data in the MDC, it will not launch an IO that the
first level VM will need to handle.  Give MDC a try by using MDISKs
for VSE, but turn MDC off in the first level VM, and give the
secondlevel VM as much storage as you can.

MDC will transform IO requests into fulltrack IOs, so with one IO you
get much more than requested; sequential processing will fly.
Random access: may vary, if the MDC is large enough you may still
benefit.

2009/4/29 Berry van Sleeuwen <berry.vansleeu...@xs4all.nl>:
> Geert,
>
>>Do you mean: attached to the VSE-guest or to the VM/ESA-guest?
>>If attached to the VSE-guest: is there still a real performance benefit
>>in attaching dasd to a 3rd level VSE-guest?
>
> Attached to the guest VM. I don't know if there would be any advantage in
> attaching to third level, other than an as-is move to a new location.
>
>>Anyway, MDC has the potential of giving your VSE-throughput a real boost
>>(it did in our case), so in order for the VSE-guest to benefit from MDC
>>in the VM/ESA system, I would:
>>- in the first level z/VM: attach the dasd to the 2nd level VM/ESA
>>guest.
>>- in the 2nd level VM/ESA: attach the dasd to SYSTEM, and define
>>fullpack MDISKs for the 3rd level VSE guest.
>
> But would that also boost non-IO load? I expect the problem is CPU load in
> some stupid program. In that case any MDC wouldn't help me for that. The
> only advantage would be an improvement of the batch processing.
>
>>Also, if enough storage is available in VSE, add more buffers to your
>>CICS LSR-pools and/or database system.
>
> Storage enough. We have 512M spare in the host VM that isn't used. And the
> VSE runs NOPDS so we can increase it just by adding virtual storage in the
> VSE guest directory. If VM runs out of storage (or starts paging at any
> serious level) we can add virual storage to the guest VM.
>
> Regards, Berry.
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to