virtual memory 4501

one of the things that some of the paging simulation work done at the science center

looked at the trade-offs of different sized pages. in (severely) real storage constrained environments ... smaller page sizes met that applications could run efficiently with smaller real storage requirements (i.e. portions of larger page that weren't actually needed by an application would not need to occupy real storage). larger page sizes tended to increase the real storage required by an application to run ... but it tended to result in more efficient use of the paging i-o infrastructure moving larger blocks of data to-from memory.

this was somewhat seen in the 370 architecture from the early 70s. it offered both 2k and 4k page sizes. the dos-vs and vs1 operating systems used 2k page sizes ... since they tended to run on lower end 370 machines which typically had a couple hundred k of real memory (sometimes after fixed kernel requirements ... maybe 100k to 200k ... i.e. 50-100 2k pages ... or 25-50 4k pages). os-vs2 and vm ran with 4k pages.

the trade-off was seen in transition of vs1 to the later 370-148 which had 1mbyte real storage.

vs1 was adaptation of real storage MFT system to virtual memory ... somewhat akin to the earlier description of svs

vs1 would define a single 4mbyte virtual address space from which it ran multiple applications ... performing paging operations using 2k pages (typically 370-135 and 370-145 with 256kbyte to 512kbyte real storage).

in the mid-70s, the 138 and 148 follow-on to 135-145 were introduced with 148 configuration typically having 1mbyte of real storage.

A lot of 370-148 configurations operated with vm-370 as the base host system running vs1 in a 4mbyte "virtual machine". vs1 would be configured that its 4mbyte virtual address space would be mapped one-for-one to the virtual machine address space. As a result, all 4mbytes of the virtual address space would appear to always be resident and never result in a page fault. A special interface was defined that allowed VM-370 to reflect any virtual machine page faults to the VS1 supervisor (allowing the VS1 supervisor to perform task switch ... although the VS1 supervisor wouldn't otherwise have to perform any operation in support of paging). When VM-370 finished processing the page replacement ... it then could single the VS1 supervisor that the page was now available.

So there were some number of comparisons running VS1 on a "bare" 370-148 with 1mbyte real storage and 2k virtual pages and running VS1 on the same hardware in a virtual machine under VM-370 doing paging with 4k virtual pages (with the total real storage available to VS1 operation reduced by the VM-370 fixed kernel requirements). It turned out that VS1 frequently ran faster under VM-370 than it did running on the bare hardware; i.e. VM-370 performing 4k page i-o operations (for VS1 ... rather than relying on VS1 to perform 2k page i-o operations) more than offset the overhead degradation of operating in a virtual machine.

The issue was that in the mid-70s with the transition to 1mbyte (and larger real storage sizes) had changed from being significantly real-storage constrained ... to only being moderately real-storage constrained ... and that the page fault handling and page i-o operations were starting to dominate as source of system bottleneck.

--