Re: backward architecture, The Design of Design

Lynn Wheeler <lynn@garlic.com> writes:

little over decade ago I was asked to track down decision to add virtual
memory to all 370s and found staff to executive making the
decision. Basically OS/360 MVT storage management was so bad, the
execution regions had to be specified four times larger than used, as a
result a 1mbyte 370/165 normally would only run four regions
concurrently, insufficient to keep system busy and justified. Mapping
MVT to a 16mbye virtual address space (aka VS2/SVS) would allow
increasing number of concurrently running regions by factor of four
times (with little or no paging), keeping 165 systems busy
... overlapping execution with disk I/O.

In some sense IBM CKD DASD was tech trade-off being able to use
disk&channel capacity to search for information because of limited real
memory for keeping tract of it. By the mid-70s that trade-off was
starting to invert. In the early 80s, I was also pontificating that
since mid-60s 360, relative system disk throughput had declined by an
order of magnitude ... disks had gotten 3-5 times faster while systems
had gotten 40-50 times faster. A disk division executive took exception
to my statements and assigned the division performance group to refute
it. After a couple weeks, they came back and explained that I had
understated the problem. They then respun the analysis for
recommendations for optimizing disk configurations for system throughput
... that was presented at IBM mainframe user groups.

Now the MVT->VS2/SVS was actually capped at 15 concurrently executing
regions because it was (still) using 4bit storage protect keys to keep
the regions separate (in a single 16mbyte virtual address space)
... which prompted SVS->MVS with a different virtual address space for
each executing region. However the OS/360 history was heavily pointer
passing APIs ... and to facilitate kernel calls, an 8mbyte image of the
MVS kernel was mapped into each 16mbyte application address space (so
kernel code to easily fetch/store application data). However, for MVS,
MVT subsystems were given their own virtual address space ... so for API
parameter and returning information a one common segment area (CSA) was
(also) mapped into every 16mbyte virtual address space (leaving 7mbytes
for application).  However, requirement for CSA space is somewhat
proportional to number of number of subsystems and number of
concurrently running applications ... and CSA quickly becomes multiple
segement area and the "Common System Area" ... and by late 70s and 3033,
it was common to be 5-6mbytes (leaving 2-3mbytes for applications) and
threatening to become 8mbytes (leaving zero).

That was part of the mad rush to get to 370/XA (31-bit) and MVS/XA
(while separate virtual address spaces theoretically allowed for
large number of concurrently computing programs, being able to
overlap execution with waiting on disk i/o, the CSA kludge had
severely capped it).

There were a number of 3033 temporary hacks. One was retrofitting part
of 370/xa access registers to 3033 as "dual-address space". A called
subsystem in its own address space could have a secondary address space
pointing to the calling application's address space ... so didn't
require CSA for API passing&returning information. They also took two
"unused" bits from page table to prefix to real page number ... while
all instructions could only specify real & virtual 24bit address
(16mbytes), it was possible to have virtual->real mapping up to 64mbytes
for execution (attaching more than 16mbytes of real storage to 3033).


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