Brian Inglis <[EMAIL PROTECTED]> writes:
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
DCSS.
there was eventually a decision to release some amount of the features
as the vm370 resource manager. some collected posts on scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare
and other posts on page management
http://www.garlic.com/~lynn/subtopic.html#wsclock
and for something really different old communication (from 1982)
about work i had done as undergraduate in the 60s (also in this
thread):
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
http://www.garlic.com/~lynn/subboyd.html#boyd
and various URLs from around the web mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
* 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.
http://www.garlic.com/~lynn/subtopic.html#unbundle
* 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:
http://www.garlic.com/~lynn/subtopic.html#bounce
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)
http://www.garlic.com/~lynn/subtopic.html#smp
....
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?
