From: lynn@garlic.com   
      
   John Levine  writes:   
   > The last widely used single address space systems I can think of were OS/VS1   
   > and OS/VS2 SVS, each of which provided a single full sized address space in   
   > which they essentially ran their real memory predecessors MFT and MVT.  As   
   > Lynn has often told us, operating system bloat forced them quickly to go   
   > to MVS, an address space per process.   
      
   they had two kinds of bloat. original decision to add virtual memory was   
   because of MVT storage management problems, having to specify each   
   region (concurrent execution) four times larger than actually used, as a   
   result a typical 1mbyte 370/165 only ran four concurrent regions,   
   insufficient to keep system busy and justified. Going to 16mbyte virtual   
   address space (VS2/SVS) allowed concurrent regions to be increased by   
   factor of four (sort of like running MVT in a 16mbyte CP67 virtual   
   machine ... aka CP67 recursor to VM370), with little or no paging   
   ... although caped at 15 because of 4bit storage protects keys.   
      
   Problem was that as systems got larger/faster needed to move past 15   
   concurrent regions ... which resulted in giving each concurrently   
   executing region/program, their own 16mbyte virtual address space   
   (VS2/MVS). However, OS/360 & descendents were heavily pointer passing   
   APIs (creating a different problem) and so they mapped a 8mbyte image of   
   the MVS kernel into every 16mbyte virtual address space (leaving   
   8mbytes). Then because each subsystem was moved into their separate   
   16mbyte virtual address space, the 1mbyte "Common Segment Area" (CSA)   
   was mapped into every virtual address space for passing arguments/data   
   back and forth between applications and subsystems (leaving 7mbytes).   
      
   Then because the space requirements for passing arguments/data back and   
   forth was somewhat proportional to number of subsystems and concurrently   
   running regions/applications, the CSA started to explode becoming the   
   Common System Area (CSA) running 5-6mbytes (leaving 2-3mbytes for   
   regions/applications) and threatening to become 8mbytes (leaving zero   
   for regions/applications). At the same time the number of concurrently   
   running applications space requirements was exceeding 16mbytes real   
   address ... and 2nd half 70s, 3033s were retrofitted for 64mbytes real   
   addressing by taking two unused bits in page table entry and prefixing   
   them to the 12bit (4k) real page number for 14bits or 64mbyte   
   (instructions were still 16mbyte, but virtual pages could be   
   loaded and run "above the 16mbyte line").   
      
   Then part of 370/xa "access registers" was retrofitted to 3033 for dual   
   address space mode. Calls to subsystems, could move the caller's address   
   space pointer into the secondary address space register and the   
   subsystem address space pointer was moved into primary. Subsystems then   
   could access the caller's (secondary) virtual address space w/o needing   
   data be passed back&forth in CSA. For 370/xa, program call/return   
   instructions could perform the address space primary/secondary switches   
   all in hardware.   
      
   I had also started pontificating that lot of OS/360 had heavily   
   leveraged I/O system to compensate for limited real storage (and   
   descendents had inherited it). In early 80s, I wrote a tome that   
   relative system disk I/O throughput had declined by an order of   
   magnitude (disks throughput got 3-5 times faster while systems got 40-50   
   times faster (major motivation for constantly needing increasingly   
   number of concurrently executing programs). Disk division executive took   
   exception and directed the division performance organization to refute   
   my claims. After a couple weeks, they came back and basically said that   
   I had slightly understated the problem. They then respun the analysis   
   for SHARE (user group) presentation on how to configure/manage disks for   
   improved system throughput (16Aug1984, SHARE 63, B874).   
      
   3033 above the "16mbyte" line hack: There were problems with parts of   
   system that required virtual pages below the "16mbyte line". Introduced   
   with 370 was I/O channel program IDALs that were full-word   
   addresses. Somebody came up with idea to use IDALs to write a virtual   
   page (above 16mbyte) to disk and then read it back into address   
   <16mbyte. I gave them a hack using virtual address space table that   
   filled in page table entries with the >16mbyte page number and <16mbyte   
   page number and use MVCL instruction to copy the virtual page from above   
   16mbyte line to below the line.   
      
   --   
   virtualization experience starting Jan1968, online at home since Mar1970   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)