VM maclib reference

the original superset of DCSS, I had started on CP-67 and referred to it as virtual memory management (VMM) ... this included handling CMS disk i-o as paged mapped operations (as opposed to emulated real i-o with CCWs, locking & unlocking pages, etc) and various enhancements for sharing pages. recent posting

part of the idea for my vmm work came from having been exposed to some tss-360 at the university ... and part from some of the multics stuff going on in the 5th floor ... science center and cp67 stuff was on the 4th floor

the original r-o cms shared pages done on cp-67 was at the page level (not segment) and store protect was handled by fiddling the storage keys. cms didn't use storage keys ... so virtual machine with shared pages had the psw and storage keys fiddled; shared pages always had storage keys set to zero; if the virtual machine attempted to set storage key for shared page it was ignored, if the virtual machine attempted to set zero storage key for non-shared page it was redone to x'F'. if the virtual machine attempted to load a psw with a zero protect key, it was reset to x'F'.

for 370 virtual memory, there was all sorts of new hardware stuff defined, including r-o segment protect and selective invalidate instructions. for r-o segment protect, the segment table entry (in the virtual address space table) for a specific segment could have the r-o bit turned on. the segment table entry then pointed to a set of pages in a page table. the kernel could setup address space tables so that some of the page tables were the same across multiple address spaces (aka shared). however, whether or not a particular virtual address space had read-write or read-only access to a shared page table was set in the address space (segment) table (aka you could have a mix of address spaces with r-o and r-w sharing of the same page table).

for the cms morph to 370 ... the shared pages were reorganized into segment and was planning on using the new 370 r-o segment protect facility. however, before 370 virtual memory was announced an issue arose with 370-165 hardware support for virtual memory. an esacallation meeting in pok, the 165 engineers said that it would take an extra six months to implement segment protect and selective invalidates. the vs2 system people said that they had no need for segment protect and that their system would never do more than five page i-os per second and they could do batch page steal once a second for that many pages (so the different of doing a global PTLB once a second or doing five individual IPTEs once a second was negligable). It was only vm370 that came out for segment protect and high paging rates. the resolution was to drop the additional features from the 370 announcement so that virtual memory could support six months earlier.

this left cms in a bind ... the mechanism they were planning on using for protecting shared segments disappeared from the machines. they were forced to punt and return to the cp-67 mechanism of protecting individual shared pages.

not too long latter, virtual machine buttist (VMA) microcode buttist was introduced ... which included support for loading new PSWs in the hardware (rather than taking a privilege interrupt into the cp kernel and emulating the instruction). this and other VMA features represented thruput enhancement (by doing some of the virtual machine stuff directly in hardware rather than having to interrupt into the cp kernel for everything). for cms, the problem was that the VMA microcode buttist didn't no about the fiddling rules for protect keys and so VMA couldn't be turned on for CMS virtual machines running with shared pages.

so coming up to vm-370 release 3, there was some work done to allow CMS virtual machines to run with VMA. basically since there was no way of actually protecting the shared pages ... the paradigm changed to allow shared pages to be modified ... but catching such modifications before any but the virtual machine making the change saw it. basically on every task switch ... dispatcher would check to see if it was going to stop running a virtual machine with shared pages. it would then scan that virtual machine's virtual pages for any shared pages that had been modified. if the dispatcher found any, it would unshare the shared system (for the virtual machine that made the modifications) and update the shared tables to indicate that the recently modified page(s) weren't in real memory and would have to be paged in from disk.

at this time, normal cms had a single shared segment with 16 shared pages. on the avg. running a cms workload with VMA saved X percent cpu ... and checking 16 shared pages on every task switch cost Y percen cpu ... where Y was normally less than X ... yielding an overall

however, for actual vm-370 release 3, it was decided to also pickup a subset of my VMM changes and release them as DCSS. Now part of the changes picked up was that I had modified some amount of additional CMS code to make it run in shared segment (rewritten part of the standard cms editor to make the code shareable as well as some amount of other code). so what shipped in release 3 was the DCSS changes where CMS now normally ran with 32 shared pages and with VMA turned on. However, doubling the number of shared pages, then doubled the nominally greater than X.

this was even further aggrevated with shipping of multiprocessor support. The checking gimmick was predicated on treating the shared pages as private while a specific virtual machine was actually running ... and then catching and fixing any changes before switching to a different virtual machine. with 2-way smp support, you could now have two virtual machines running concurrently ... simultaneously accessing the same shared pages (violating the priniciples of the gimmick). so to perpetuate the fixup gimmick, real processor specific shared segments-pages were defined. now, in addition to checking whether the previous virtual machine had modified any shared pages ... before you went to run a new virtual machine, you had to check whether the new virtual machine had its virtual memory table entries pointing to the shared segments specific for the processor it was about to run on. VMA), but the processor specific page table pointer fiddling really blew it out of the water.

the posting reference above

i had made the full vmm changes available internally before vm370 release 3, and they were running at places like HONE

and was using it along with extensive use of the APL interpreter running with something like 64 shared pages. the release 3 gimmick for using VMA would mean that HONE was having to check nearly 100 shared pages on every task switch. furthermore, since they workload was heavily apl interpreter end bound ... VMA buttist provided them negligible thruput improvement.

other random past posts about dcss, dmksnt, loadsys, etc:

random past posts mentioning 165 problem with implementing the full 370 virtual memory architecture:

--