Performance and Capacity Planning 739

before doing release 4 support for 158 & 168 (two-processor) smp, there were two other projects (that were never annonced), vamps (a 5-way smp ... implemented with lower level 370 processor that didn't have caches ... and so there wasn't a cache problem) and logical machines (a 16-way smp using 158 engines that didn't implement standard cache consistency ... only compare&swap and a couple other operations).

the strong cache consistency of 370 ... gave problems when they tried to tie a pair of two-processor 3081s into 4-way 3084. the 370 flavor had cache running the same speed as machine cycle. later machines going to larger number of processors started running the cache had much faster cycle speeds than the rest of the infrastructure (so the cross-cache invalidation slow-down didn't slow down the processor cycle speed).

besides the influence of future system on 801-risk

aka swing the pendulem from the extreme future system hardware complexity to extreme hardware simplicity of 801-risc ... where there were even statements about trading off increased software complexity in 801-risc for simpler hardware.

the strong cache consistency problems in 370 influence "harvard" architecutre and separate I & D caches w-o any provision for cache consistency (even between I & D caches on the same chip). oak ... which was a 4-way (6000) processor complex with shared memory didn't provide for cache consistency. There were two modes ... a virtual "segment" was either defined as "cached" and not consistent or a virtual "segment" could be tagged as consistent and never "cached".

The executive we reported to when we were doing ha-cmp

went over to head up powerpc-comserset ... when that effort was started. the transition from rios-power to powerpc took some amount of rework to introduce concept of cache consistency.