Multiple address spaces 2895

MVS ... a long history

from above ...

OS-VS1 provided a single virtual storage address space system, while OS-VS2 allowed multiple virtual storage address spaces. However, the first release was restricted to a single virtual storage address space and became known as OS-VS2 SVS. The following release, made available in July 1974, contained multiple virtual storage, address space support and was named OS-VS2 MVS Release 2. Both OS-VS1 and OS-VS2 SVS supported a total of 16MB of virtual storage. Because the OS-VS2 MVS release supported multiple virtual storage address spaces, each of which provided 16MB, most people buttumed it would be years before additional storage would be required.

... snip ...

note because of the pervasive use of pointing pbutting paradigm, half of each virtual address space was occupied by the 8mbyte kernel image, with the other half supposedly for applications. however, with the transition from (effectively) all applications laid out in the same address space (as was the case in MVT and SVS), all the subsystems applications occupied their own address space. In order to support the pointer pbutting paradigm between applications address space and subsystem address space ... the "common segment" was created. In larger configuraitons with lots of subsystems and applications, the "common segment" could occupy as much as five megabytes that appeared in every virtual address space (taken out of the eight mbytes supposedly available for applications) ... leaving only a maximum of three mbytes for application actual instructions and data.

the 370-168 TLB (table look aside buffer) was tailored for MVS. the 168 hardware TLB had 128 (cached) entries for translating virtual to real addresses. Specific bits were used from the virtual address to select a subset of TLB-entriess ... to see if there was already a 168, one of the bits was the "8mbyte" bit ... which resulted in half of the entries being available for MVS kernel addresses and half of the entries being available for applications.

not however, both VS1 and CMS virtual address spaces typically started at zero and rarely went over four mbytes. As a result, both VS1 and CMS rarely had any virtual addresses with the "8mbyte" bit set ... and therefor half the TLB entries on 370-168 would go unused (in vs1 and cms environments).

VS1 was the mft to virtual upgrade and became an "Endicott" product for the mid-range 370s (DOS became dos-vs for the entry virtual memory 370s and MVT became VS2 for the high-end virtual memory 370s).

where it was standard for VS2-SVS to have defined a single 16mbyte virtual address space ... a typical VS1 configuration was a single 4mbyte virtual address space. Endicott started making heavy investment in mid-range product line being vm-370 oriented. It created ECPS vm370 performance microcode buttist for the 138-148 ... a couple ECPS postings:

The vm370-vs1 handshaking was also created. A 4mbyte virtual machine would be defined for VS1. VS1 then defined a single 4mbyte virtual address space that had its pages laid out sequentially in the 4mbyte virtual machine address space. VS1 then would rely on VM to do paging operations (moving pages to-from disk). In addition to eliminating "double" paging (both VS1 and VM moving pages to-from disk), it turned out that VM did the movement to-from disk significantly more efficiently than VS1 (or for that matter VS2). On CP67, I had optimized the aggregate, complete round trip pathlength (page fault, page replacement, schedule page i-o, perform page i-o, reschedule task, etc) to a few hundred instructions. It significantly went back up in the initial morph from cp67 to vm370 ... but i got it back down again with the paging code released in the resource manager.

a couple past posts about vs2 corrupting their LRU page replacement algorithm ... and not getting it corrected until well into MVS releases (3.8+?).

misc. past posts mentioning Ludlow(?) working 3rd shift (pok 706? machine room) on initial vs2-svs prototype called AOS2.

--