On Friday, 07/28/2006 at 01:32 EST, Brian Nielsen <[EMAIL PROTECTED]> wrote: > 1) SIE breaks are going to happen for dedicated devices because of the > loss of I/O assist (requiring the higher level CP to convert the virtual > addresses to real addresses).
A SIE break will occur for all Start Subchannel (SSCH) and DIAGNOSE I/O. QDIO I/O (with the QDIO Assist) will not [necessarily] cause a SIE break. This is very useful for Linux guests that are accessing FC disks and for OSA-Express QDIO device drivers. > 2) Dedicated CPUs will reduce the number of SIE breaks (by removing the > higher level CP's dispatching timers for the guest CPU). True? Not significantly, no. The only difference with a dedicated CPU is that you exchange the SRM DSPSLICE (300ms) for a fixed 500ms time slice. Even though the CPU is dedicated, the rest of the system resources aren't and CP still needs to perform housekeeping activities. > 3) Reducing paging for the guest in the higher level CP (eg. SET RESERVED) > can help minimize SIE breaks (by reducing progam interrupts caused by DAT > not finding guest memory addresses resident in host memory). True. > 4) If said guest is z/OS, several of the conditions which trigger SIE > breaks generally don't happen frequently enough to worry about (commands > from the virtual console, IUCV/APPC instruction 0xB2F0, Diagnose > instructions). In the strictest sense, that's true. However, see the I/O discussion. Whether you perform I/O via SSCH or DIAG doesn't matter. > 5) Are there any other things (other than moving it to an LPAR) that can > be done to minimize SIE breaks for 2nd level z/OS and z/VM systems? The SRM DSPSLICE is adjustable. However, the larger you make the interval, the less responsive the system is to changes in load. I'll leave it to other, wiser heads to give advice on SIE break optimization. But you really need to look at the performance data coming out the the guest. Is it meeting its SLAs? Do you *need* to worry about SIE breaks? Alan Altmark z/VM Development IBM Endicott
