Re: third system syndrome, interactive use, The Design of Design

EricP <ThatWouldBeTelling@thevillage.com> writes:

Lynn Wheeler wrote:

For some reason AT&T longlines got an early version of my production
VM370 CSC/VM (before the multiprocessor support) ... and over the years
moved it to latest IBM 370s and propogated around to other
locations. Then comes the early 80s when next new IBM was 3081 ... which
was originally a multiprocessor only machine. The IBM corporate
marketing rep for AT&T tracks me down to ask for help with retrofitting
multiprocessor support to old CSC/VM ... concern was that all those AT&T
machines would migrate to the latest Amdahl single processor (which had
about the same processing as aggregate of the 3081 two processor).

>
Regarding retrofitting multiprocessor support to old CSC/VM,
by which I take it you mean adding SMP support to a uni-processor OS,
do you remember what changes that entailed? Presumably a lot more than
acquiring one big spinlock every time the OS was entered.
That seems like a lot of work for one person.

Charlie had invented compare&swap (for his initials CAS) when he was
doing fine-grain CP/67 multiprocessor locking at the science center
... when presented to the 370 architecture owners for adding to 370
... they said that the POK favorite son operating system (OS/360
MVT/MVS) owners that 360/67 test&set was sufficient (i.e. they had a big
kernel spin-lock) ...  this also accounted for MVS documentation saying
that two-processor support only had 1.2-1.5 times the throughput of
single processor.

I had initially done the multiprocessor kernel re-org for VM/370 for
VM/370 Release2 based CSC/VM ... but not the actual multiprocessor
support. The internal world-wide sales&marketing support HONE systems
were long time customer for my enhanced CSC/VMs and then the US HONE
datacenters were consolidated in silicon valley (trivia: when facebook
1st moves moves into silicon valley, it was into a new bldg built next
door to the former US HONE consolidated datacenter). They had added
"loosely-coupled" shared DASD support to complex of eight large systems
with load-balancing and fall-over. I then added SMP, tightly-coupled,
multiprocessor to VM/370 Release3 based CSC/VM so they could add a 2nd
processor to each system (for 16 processors total). Their two processor
systems were getting twice the throughput of single processor ... a
combination of very low overhead SMP, tightly-coupled, multiprocessor
locking support and a hack for cache affinity that improved the cache
hit ratio (with faster processing offsetting the multiprocessor
overhead).

The VM/370 SMP, tightly-coupled, multiprocessor locking was rather
modest amount of work ... compared to all the other stuff I was doing.

trivia: The future system stuff (to replace all 370) was going on during
much of this period. When FS implodes there was mad rush to stuff back
into the 370 product pipelines, including kicking off quick&dirty 3033
and 3081 in parallel
http://www.jfsowa.com/computer/memo125.htm

about the same time, I'm roped into helping with a 16-processor
tightly-coupled 370 effort and we con the 3033 processor engineers to
work on it in their spare time (a lot more interesting than remapping
168 logic to 20% faster chips) ... everybody thot it was great until
somebody tells the head of POK that it could be decades before the POK
favorite son operating system had (effective) 16-processor support (aka
their spin-lock, POK doesn't ship 16-processor SMP until after the turn
of century).  Then the head of POK invites some of us to never visit POK
again. The head of POK also manages to convince corporate to kill the
VM370 product, shutdown the development group and transfer all the
people to POK for MVS/XA (supposedly otherwise they wouldn't be able to
ship MVS/XA on time) ... Endicott eventually manages to save the VM370
product mission for the low&midrange ... but have to recreate a VM370
development group from scratch.

I then transfer out to west coast and get to wander around (both IBM &
non-IBM) datacenters in silicon valley, including disk engineering
(bldg14) and disk product test (bldg15) across the street. At the time
they are running prescheduled, 7x24, stand-alone testing ... and had
recently tried MVS but it had 15min mean-time-between failure (in that
environment, lots of faulty hardware). I offer to rewrite the I/O
supervisor to make it bullet-proof and never fail so they can have any
amount of on-demand testing, greatly improving productivity (downside
any time they have problems, they imply its my software and I have to
spend increasing time playing disk engineering diagnosing their hardware
problems). I do a (internal only) San Jose Reseach report on the I/O
Integrity work and happen to mention the MVS 15min MTBF, bringing down
the wrath of the MVS organization on my head.

--
virtualization experience starting Jan1968, online at home since Mar1970