In a message dated 3/28/2006 2:52:42 P.M. Central Standard Time, [EMAIL PROTECTED] writes:
>In a multiple CPU environment, z/OS normally only has a single engine >enabled for I/O interrupts. I think this is because the IOS supervisor >does a TPI instruction which will test for pending interrupts. If the >interrupts were enabled on a second engine, it would have fielded the >interrupt which was pended. The use of TPI increases the effiency of the >I/O processing due to decrease I/O interrupts and their overhead. A multi-processing z/OS starts out with one CPU enabled for I/O interrupts. As interrupts occur, IOS accumulates a count of all interrupts processing by switching PSWs When IOS is about to redispatch the interrupted work, it tests for one or more interrupts pending in the channel subsystem by executing the TPI instruction. If an interrupt is processed because of the TPI, IOS adds one to the TPI-fielded bucket instead of the processor-interrupted buciet. TPI allows IOS to continue processing I/O interrupts without having to restore the interrupted work's status, enable, and then immediately switch PSWs again, save status, and start processing the interrupt that was pending. This is more efficient than always reenabling and redispatching. SRM periodically computes the TPI-fielded % of interrupts from the two buckets mentioned above and checks that against CPENABLE percentages to decide if it is time to pick another CPU and change its system mask to where it can also be interrupted with I/O interrupts. This will reduce the I/O interrupt elongation factor, but at the cost of slowing down the work that is on the CPU newly enabled for interrupts. Whenever an interrupt occurs, there is a context switch between the working set of TLB entries and high-speed instruction cache of the interrupted work and that of the new context - IOS. This means that the CPU slows down a little every time an interrupt occurs, when interrupted work is redispatched, or whenever the dispatcher first dispatches a different work unit for any reason. Bill Fairchild ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html