Performance and Capacity Planning 735

all vamps processors ran identical microcode and instructions.

in vamps, the global kernel lock metaphor ... just precluded more than one processor at a time executing in the kernel. in the morph to the pure software implementation ... some amount of the kernel was parallelized, maybe a 1500-2000 instructions worth, the rest was left behind a serialized kernel lock. however, the 1500-2000 instructions that were parallelized were the highest use instructions and also implementated the queue-dequeue operations ... allowing processors that were blocked from entering the kernel to go off and attempt to do non-kernel work (rather than spinning on a lock).

standard 360-65 just had shared memory ... but not shared i-o. 360-65 attempting to simulate shared i-o with device controllers that were attached to multiple channels (aka the 360 i-o buses) 360-65 hardware configuration was frequently configured so that the same channel address on both processors connected to the same control unit at the same address.

the 360-67 smp was different ... it had a channel controller box that allowed all channels to be connected-to & addressed-by all processors.

370 reverted to the 360-65 smp model ... requiring shared i-o simulation by having shared controller connection to processor unique channels. you didn't see the return to common channel addressing until 370-xa on the 3081 (the 360-67 also had 32-bit virtual addressing mode, 370 only had 24-bit virtual addressing mode ... it also wasn't until you got to 370-xa on the 3081 that 31-bit virtual addressing was introduced).

370-158 and 370-168 offered a cost reduced, computational intensive two-processor option ... where only one processor had connected channels for i-o. in that scenario ... any application running on the processor w-o i-o connectivity and requested kernel i-o services ... the request had to be handed off to the processor with i-o connectivity. This configuration also tended to have a somewhat unanticipated side-effect that the cache-hit ratio on the processor w-o i-o connectivity tended to go up ... and therefor got more work done. the cache hit ratio on the processor with i-o connectivity could also slightly improve ... because in the two processor case ... the kernel i-o code would only be executing on one processor ... increasing the probability of local cache hit ratio for that part of the kernel.