>The channel requests an I/O interrupt. It must be processed by a specific >LPAR, but not a specific CPU.
With regard to cpenable, I believe you've missed the fact cpenable only comes into play when you're dealing with *pending* interrupts. Using the TPI (test pending interrupt) means that you won't need to go through the I/O FLIH overhead again. Instead I/O FLIH (or is it I/O SLIH) tests if more interrupts are pending and handles them as well. Only when the percentage of pending interrupts exceeds the cpenable values, a second logical cp will handle them. For dedicated cps in lpar mode, Init&Tuna for 1.12 says to use the basic mode default, which is 10,30. lpar mode default is 0,0. >it runs with only a subset of it's LCPs enabled for interrupts I have a definite problem with the wording of this. 'Enabled for interrupts' in my book is quite independent of the logical/physical cp distinction. 'enabled for interrupts' is a 7 at the appropriate point in the psw (instead of a 4 when disabled - grossly simplified). And 'disabled for interrupts' means just that - *any* type of interrupt, not just I/O interrupts. When all cps of an lpar are disabled for interrupts, then all I/O interrupts stay waiting for the lpar to handle them, i.e. to become enabled for interrupts again at least on one cp. This is independent of any cpenable setting, AFAIK. 'Elongated I/O times' stem from the lpar dispatcher not dispatching your lpar as a whole, not noticably from any cpenable setting. If a lowly weighted lpar is not dispatched, it can obviously not handle the I/O interrupt. Assuming the lpar is dispatched on one or more physical cps, and running enabled for I/O interrupts, those will be handled immediately, and *before* any 'application work' is done. If your lpar is so heavily loaded that most of the time some system routine runs disabled for I/O, then no amount of cpenable tuning will change that. Just how did you arrive at the conclusion that elongated I/O times are the source of your problem? How did you measure them? Barbara Nitz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
