virtual memory 4479

the other thing that was starting to happend by the second half of the 70s was things were starting to shift from being real memory constrained to being much more disk arm constrained.

the working set and page replacement strategies of the 60s and early were focused on real storage being frequently a highly constrained resource. however, by the second half of the 70s, disk arms were much more frequently the constrained resources .... although you could have second order effects involving paging operations putting heaving contention on disk resource, possibly creating long queues and long service times. the page thrashing with huge system page wait of the 60s could be replaced with disk arm contention with huge system page waits ... but not particularly because of excessive over commitment of real storage.

this was the late 70s shift from attempting heavy optimization of real storage use ... to attempting to trade-off real storage resources in attempt to compensate and mitigate the disk arm bottlenecks. some exploration of this subject in previous post in this thread

some of the references in the above references a comparision between a typical 360-67 cp67 configuration supporting 80 some users comfortably (on the cambridge system) to a decade plus later with a 3081 vm370 configuration supporting 300 some users with similar workload operation. the processor mips and the available "pageable pages" had increased on the order of fifty times while the numbers of supported concurrent users increased around four times. as shown in the repeated comparision the increase in number of users was relatively consistent in the increase in disk arm performance (which had contributed to my comment that relative system disk thruput had declined by a factor of 10 times during the period). one of the old references mentioned in the post referenced above:

the issue became is it possible to develop strategies that better optimized the use of disk arms ... possibly at the sacrifice of either processor and-or real storage optimization.

one such strategy was "big pages" for paging in the early 80s for both vm370 and mvs. part of this was 3380 disk arm thruput was maybe 3-4 times that of the earlier 2314 disk arm ... however the data transfer was ten times as much. "big pages" went to creating "on-the-fly" full-track clusters of 4k pages. paging area on disk was layed out possibly ten to twenty times larger than actually needed and managed by a "moving cursor" algorithm ... somewhat similar to some of the log structured filesystem work that would appear a decade later (which were done for similar objectives to try and drastically improve the disk arm use efficiency).

for page-out ... a full-tracks worth of pages from an address space would be collected together (whether the pages had been changed or not during their current residency in storage) and written as one operation. later when there was a page fault for any 4k page in a "big page" ... the whole track would be read into real storage. This profligate movement of pages might increase the total real storage required by an application by 20-30percent (and similar increase in number of bytes moved) ... but was traded off by redcuing the disk arm resource for moving each page by 90 percent. this also could play fast and loose with the accuracy of tracking what virtual pages were actually the least recently used ... but the trade-off of drastically improving the efficiency of disk arm resource for moving pages showed a net win (as something that represented the primary bottleneck in the infrastructure).

with such a big increase in the amount of real storage ... and the shifting of major system bottleneck to disk arm ... there could be significant system thruput trade-offs that might result in much less efficient use of real storage if it might drastically improve the overall system thruput situation dealing with disk arm bottleneck.

i had also done analogous efficiency with the page mapped filesystem i had developed

improving the probability of contiguous allocation for many filesystem objects and being able to dynamically adjusting how large a block transfer could be done when accessing the object (based on configuration, load) ... again trading off the efficiency of real-storage utilization for improved diak arm efficiency.

misc. past posts discussing the "big page" strategy from a couple decades ago.

--