The Future of CPUs: What's After Multi-Core?
(too old to reply)
Anne & Lynn Wheeler
2006-12-20 19:37:51 UTC
IME the IBM VM guys had very good ideas for interaction using the
corporate products and facilities, even though it has never been
funded adequately and often nearly terminated.
They were much better than the batch guys at letting the users fully
use all the machines' capabilities, providing nearly 100% capacity and
keeping terminal response averages close to 0.1s; the batch guys were
better at using up all the machines' capabilities, and the users
considered themselves lucky to have 70% capacity available and get 1s
terminal response times.
The really cool thing about VM systems is that you can do anything
with the software under timesharing: develop a new OS, test a changed
OS, trace the execution of an OS.
Once found a bug crashing a DB product only after tracing about a
million instructions, a few times over to get it exactly right, with
very selective output, sufficient to pinpoint the faulty code: try
doing that on a real front panel or console!
for some total drift ... a different reference to "tracing" in support of
semi-automated program reorganization to optimize execution for virtual
memory environment
http://www.garlic.com/~lynn/2006x.html#1 IBM sues make of Intel-based Mainframe clones

as an undergraduate in the 60s, i had done dynamic adaptive resource
management ... it was sometimes referred to as fair share scheduling
since the default resource management policy was fair share. this
was shipped as part cp67 for 360/67.

in the morph from cp67 to vm370 ... much of it was dropped. charlie's cp67
multiprocessor support also didn't make it into vm370.

i had done a lot of pathlength optimization and fastpath stuff for cp67
which was also dropped in the morph to vm370 ... i helped put a small
amount of that back into vm370 release1 plc9 ... a couple past posts
mentioning some of the cp67 pathlength stuff
http://www.garlic.com/~lynn/93.html#1 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14

i then got to work on porting a bunch of stuff that i had done for cp67 to
vm370 ... some recent posts (includes old email from the early and mid 70s)
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#10 long ago and far away, vm370 from early/mid 70s

and of course mentioned in the above referenced email ... a small amount
of the virtual memory management stuff showed up in vm370 release 3 as

there was eventually a decision to release some amount of the features
as the vm370 resource manager. some collected posts on scheduling
and other posts on page management
and for something really different old communication (from 1982)
about work i had done as undergraduate in the 60s (also in this
http://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's after Multi-Core?

in any case, some resources manager issues/features

* by continually doing real time dynamical monitoring and adjusting
operations, I was able to operate at much higher resource utilization
and still provide decent level of service. prior to resource manager
ship, somebody from corporate stated that the current state of the art
for resource managers were large number of static tuning parameters
and that the "resource manager" couldn't be considered really advanced
unless it had some number of static tuning parameters (installation
system tuning expert would look at daily, weekly and monthly activity
... and would select some set of static tuning values that seemed to
be suited to that installation). it did absolutely no good explaining
that real-time dynamic monitoring and adapting was much more advanced
that static tuning parameters. so, in order to get final corporate
release approval ... i had to implement some number of static tuning
parameters. I fully documented the implementation and formulas and the
source code was readily available. Nobody seemed to realize that it
was a joke ... somewhat from "operations research" ... it had to do
with "degrees of freedom" ... aka the static tuning parameters had
much less degrees of freedom than the dynamic adaptive features.

i had always thot that real-time dynamic adaptive control was preferable
to static parameters ... but it took another couple decades for a lot of
the rest of the operating systems to catch up. it is now fairly evident ...
even showing up in all sorts of embedded processors for real-time control
and optimization. for some slight boyd dynamic adaptive drift
http://www.garlic.com/~lynn/94.html#8 scheduling & dynamic adaptive
and collected posts mentioning boyd
and various URLs from around the web mentioning boyd

* there was transition in the mid-70s with respect to charging for
software. the 23jun69 unbundling announcement had introduced charging
for application software (somewhat because of gov. litigation). however
the excuse was that kernel software should still be free since it
was required for operation of the hardware. however, with the advent
of clone processors by the mid-70s, the opinion was starting to shift,
and the resource manager got chosen to be the guinea pig for kernel
software charging. as a result, i got to spend some amount of time with
business and legal people on kernel software charging.

* some amount of the code in the resource manager had been originally
built for multiprocessor operation .... it was then added to base
vm370 system that didn't have support for multiprocessor hardware
operation. the next release of vm370 did introduce support for
multiprocessor hardware operation ... some amount based on the VAMPS
work ... misc. past posts mentioning vamps multiprocessor work:

the problem was that the multiprocessor support was going to be part
of the (still) free, base kernel (aka hardware support ) ... while
much of the multiprocessor kernel code structure was part of the
"priced" resource manager (and pricing policy said that there
couldn't be free software that had priced software prerequisite).
so before the multiprocessor support was shipped, a lot of the
resource manager code base was re-organized into the free kernel.
lots of past posts mentioning multiprocessor support (and/or charlie's
invention of compare&swap instruction)


previous posts in this thread:
http://www.garlic.com/~lynn/2006t.html#27 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#31 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#32 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#36 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#42 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#49 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006t.html#50 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#0 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#6 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#7 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#8 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#9 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#10 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006v.html#21 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#2 The Future of CPUs: What's After Multi-Core?
Anne & Lynn Wheeler
2006-12-20 22:54:45 UTC
if you go back to 370s ... there were some 1.5mbyte/sec channels
(primarily driven at that rate by fixed head disks). 3380 disks and
3880 disk controllers increased that to 3mbyte/sec operation (and the
newer generation of 3mbyte/sec channels on various processors seen in
the 80s). the earlier generation of channels did a protocol handshake
on every byte transferred. the new 3mbyte/sec "data streaming"
channels relaxed that requirement ... which both increased the data
rate ... but also doubled the maximum channel distance from 200ft to
400ft i.e. you could have a machine room configuration with
controllers out at a 400ft radius rather than just a 200ft radius. The
200ft limitation had gotten so severe for some installations that
there were starting to appear multi-floor configurations (i.e. instead
of a 200ft radius circle limitation ... a 200ft radius sphere).
http://www.garlic.com/~lynn/2006x.html#11 The Future of CPUs: What's After Multi-Core?

for other topic drift, i had done some work in the disk engineering
(bldg14) and disk product test (bldg15) labs. ... misc. past posts
mentioning work in bldg14 &/or bldg15

and misc. past posts this year mentioning 3380 disks and/or 3880
disk controllers
http://www.garlic.com/~lynn/2006.html#4 Average Seek times are pretty confusing
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006g.html#0 IBM 3380 and 3880 maintenance docs needed
http://www.garlic.com/~lynn/2006i.html#12 Mainframe near history (IBM 3380 and 3880 docs)
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#2 virtual memory
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006j.html#14 virtual memory
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#13 virtual memory
http://www.garlic.com/~lynn/2006l.html#18 virtual memory
http://www.garlic.com/~lynn/2006m.html#5 Track capacity?
http://www.garlic.com/~lynn/2006m.html#8 Track capacity?
http://www.garlic.com/~lynn/2006m.html#13 Track capacity?
http://www.garlic.com/~lynn/2006n.html#8 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006n.html#33 CRAM, DataCell, and 3850
http://www.garlic.com/~lynn/2006n.html#35 The very first text editor
http://www.garlic.com/~lynn/2006o.html#44 When Does Folklore Begin???
http://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#40 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#33 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006v.html#0 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006v.html#16 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#17 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders?