Regarding interrupt sharing architectures

well in 360 ... there were channels which were typically shared i-o bus. the processor could mask interrrupts from individual channels. allowing interrupts from a channel allowed that any pending interrupts from devices on that channel could be presented.

an i-o interrupt would have the processor load a new PSW (program status word, contains instruction address, interrupt masking bits, bunch of other stuff) from the i-o new psw location (this new psw normally specified masking all interrupts) ... and storee the current PSW into the I-O old psw field.

OS interrupt routines were frequently referred to as FLIH (first level interrupt handlers) which would identify the running task, saved the current registers, copied in the old PSW information saving the instruction address, etc. There was typically a FLIH specific to each interrupt type (i-o, program, machine, supervisor call, external). The I-O FLIH would pick up the device address from the i-o old PSW field and locate the related control block structures.

the low-end and mid-range 360s typically had integrated channels ... i.e. they had microprocessing engines which was shared between the microcode that implemented 360 instruction set and the microcode that implemented the channel logic.

an identified thruput issue in 360 ... was the SIO (start i-o) instruction ... would interrogate the channel, control unit, and device as part of its operation. channel distances to a control unit could be up to 200'. The various propogation and processing dalays could mean that SIO instruction could take a very long time.

for 370, they introduced a new instruction SIOF (start i-o fast) ... which would basically interrogate the channel and pbutt off the information and not wait to hear back from the control unit and device. a new type of I-O interrupt was also defined ... if there was unusual status in the control unit or the device ... in the 360, it would be indicated as part of the completion of the SIO instruction. With 370, the SIOF instruction had already completed ... so any unusual selection status back from the control unit or the device now had to be presented as a new i-o interrupt flavor.

however, interrupts themselves had a couple of thruput issues. first in the higher performance cache machines ... asyncronous interrupt could have all sort of bad effects on cache hit ratios. also on large systems there was an issue with device i-o redrive latency. in a big system there might be a queue of requests from different sources for the same device. a device would complete some operation and queue and interrupt. from the time the interrupt was queued, until the operating system took the interrupt, processed the interrupt, discovered there was some queued i-o for the device ... and redrove i-o to the device could represent quite a bit of device idle time. compound this with systems that might have several hundred devices ... this could represent some amount of inefficiency.

370-XA added bump storage and expanded channel function with some high-speed dedicated asyncronous processors. a new type of processor instruction could add stuff to a device i-o queue managed by the channel processor. the processor could also specify that i-o completion was to be placed on a queue of pending requests ... also available to the processor. the channel processor could now do real-time queuing of device i-o completion and immedate restart the device with the next request in the queue.

this was also frequently referred to as i-o handling offload. the issue here was that some of the operating systems had something like a few 10k pathlength to take i-o interrupt and get around to doing an i-o device redrive.

in the late 70s ... just prior to introduction of 370-XA ... i was wandering around the disk engineering lab ... and they had this problem with regression testing of disk technology ("testcells") in engineering development. they had tried doing some of this in a traditional operating system environment ... and found that the operating system MTBF was something like 15 minutes. As a result they were scheduling stand-alone machine time between all the various testcells contending for regression time. So i thot I would rewrite an operating system i-o subsystem to be failure bullet proof so they could concurrently work with all testcells concurrently ... not having to wait for stand-alone test time.

another thing i did was to cleanup the total pathlength so device i-o redrive time was a frew hundred instructions instead of a few 10k insruction pathlength. i claimed that this would significantly mitigate the requirement for doing i-o offload in 370-xa.

this was just a hypothetical argument (somewhat to highlight how inefficient some kernel implementation pathlengths were). a number of years earlier, I had done VAMPs ... a multiprocessor system (that never shipped to customers

that had multiple close-in microcoded engines (in addition to the processor microcode engines) all on the same memory bus. i had designed a queued i-o offload interface for vamps.

--