Hi thanks for all the replies so far. I've just read the the z/os abcs vol 10 about I/O processing and have some thoughts about CPENABLE First we are running (10,30) which seems to be IBMs current recommendation for Z9.
So is this what happens? The channel requests an I/O interrupt. It must be processed by a specific LPAR, but not a specific CPU. If CPENABLE(0,0) was in effect, any LCP dispatched on the target LPAR could process the I/O, and would do so ahead of normal work. Ie the task would stop waiting and become ready, after which it's dispatch priority within the LPAR would come into play. If an LPAR is using CPENABLE(10,30) or some other none zero value, it runs with only a subset of it's LCPs enabled for interrupts. If none of these LCPs happen to be dispatched to the LPAR, the interrupt remains pending until other LPAR relinquishes one of it's LCPS, freeing a physical CP to dispatch one of the LCPs enabled for interrupts. When the systems are capped, a z/os is more likely to have a queue of ready work, and more likely to hold onto a CP until it is taken away by the "processor running time" value, which is between 12.5 and 25 millisecs. In this case setting CPENABLE(0,0) on just the low weight LPAR should mean the interrupt is serviced more quickly (but will have a downside in terms of CPU cache). So I am thinking I should look in this order 1) Reduce the online LCPs on each LPAR to match the peak demand of the LPAR, preferably using IRD to so it automatically. 2) If this does not reduce enough, try CPENABLE(0,0) on the small LPAR 3) If this does not reduce enough, try manually setting the processor running time below 12 miilisecs on the HMC. Any thoughts would be appreciated. Joe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
