Re: Tonight's tradeoff

mitchalsup@aol.com (MitchAlsup1) writes:

{{I consider 360/67 as the beginning of paging; although Multics may be
the beginning.}}

Science center thot IBM could get MIT MULTICS ... but went to GE. Then
the IBM mission for virtual memory/paging went to "new" TSS/360
group. Science Center modified a 360/40 with virtual memory & paging
pending availability of 360/67 standard with virtual memory (and
cp40/cms morphs into cp67/cms).
Melinda's history web pages
http://www.leeandmelindavarian.com/Melinda#VMHist
from (lots of early history, some CTSS/7094 went to 5th flr and Multics
and others went to IBM science center on 4th flr)
http://www.leeandmelindavarian.com/Melinda/neuvm.pdf
footnote from Les Comeau:
Since the early time-sharing experiments used base and limit registers
for relocation, they had to roll in and roll out entire programs when
switching users....Virtual memory, with its paging technique, was
expected to reduce significantly the time spent waiting for an exchange
of user programs.
What was most significant was that the commitment to virtual memory was
backed with no successful experience. A system of that period that had
implemented virtual memory was the Ferranti Atlas computer, and that was
known not to be working well.  What was frightening is that nobody who
was setting this virtual memory direction at IBM knew why Atlas didn't
work.35
.. snip ...
Atlas  reference (gone?) but lives free at wayback):
https://web.archive.org/web/20121118232455/http://www.ics.uci.edu/~bic/courses/JaverOS/ch8.pdf
from above:
Paging can be credited to the designers of the ATLAS computer, who
employed an associative memory for the address mapping [Kilburn, et
al., 1962]. For the ATLAS computer, |w| = 9 (resulting in 512 words
per page), |p| = 11 (resulting in 2024 pages), and f = 5 (resulting in
32 page frames). Thus a 220-word virtual memory was provided for a
214- word machine. But the original ATLAS operating system employed
paging solely as a means of implementing a large virtual memory;
multiprogramming of user processes was not attempted initially, and
thus no process id's had to be recorded in the associative memory. The
search for a match was performed only on the page number p.
.. snip ...
I was undergraduate at univ and was hired fulltime responsible for
OS/360. The univ. had gotten a 360/67 for tss/360, but was running as
360/65 (univ. shutdown datacenter on weekends and I had whole place
dedicated, 48hrs w/o sleep did make monday classes hard).
Then CSC came out to install CP67 (3rd installation after CSC itself and
MIT Lincoln Labs) and I mostly played with it in my weekend time.  This
early release had very rudimentary page replacement algorithm and no
page thrashing controls. I did (global LRU) reference bit scan
and dynamic adaptive page thrashing controls.
Nearly 15yrs later at Dec81 ACM SIGOPS, Jim Gray ask if I could help a
Tandem co-worker get Stanford Phd .... it involved similar global LRU to
the work that I had done in the 60s and there were "local LRU" forces
from the 60s lobbying hard not to award a Phd (that wasn't "local
LRU"). I had real live data from a CP/67 with global LRU on 768kbyte
(104 pageable pages) 360/67 with 80users that had better response and
throughput compared to a CP/67 (with nearly identical type of workload
but 35users) that implemented 60s "local LRU" implementation and 1mbyte
360/67 (155 pageable pages after fixed storage) ... aka half the users
and 50% more real paging storage.
a decade ago, I was asked to track down decision to add virtual memory
to all 370s ... found somebody involved, archived posts with pieces
of the email exchange:
https://www.garlic.com/~lynn//2011d.html#73
--
virtualization experience starting Jan1968, online at home since Mar1970