Deutsch English Français Italiano |
<87jzk3n62r.fsf@localhost> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler <lynn@garlic.com> Newsgroups: comp.arch Subject: Re: third system syndrome, interactive use, The Design of Design Date: Wed, 08 May 2024 15:10:20 -1000 Organization: Wheeler&Wheeler Lines: 84 Message-ID: <87jzk3n62r.fsf@localhost> References: <v03uh5$gbd5$1@dont-email.me> <v1dud5$3e2c6$1@dont-email.me> <v1e0h2$15vm$1@gal.iecc.com> <18997836ff477aadd027459cf387218c@www.novabbs.org> <v1epkf$1ptf$3@gal.iecc.com> <87jzk4kwwz.fsf@localhost> <GAR_N.74964$Y79f.19203@fx16.iad> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Thu, 09 May 2024 03:10:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="c5b89ced7521d2428a176623cef093ad"; logging-data="302145"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18AH01ZNlwSIzjp4Qr9wRe1aL9HTUBhUtk=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:kUhwNpZiR9eTeRA/MrZX0jXpDIA= sha1:Oc5WBkefHf+XAalEn1HvYdRD70M= Bytes: 6127 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