The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
dcartwri...@ymail.com (David Cartwright) writes: > At Monsanto Europe in Brussels about 1976 I wrote some mods to VM/370 to > defeat Shadow Page Tables for V=R machines so we could run MVS under > VM/370 without a crippling overhead. I sent that code out into the world on > some (Waterloo?) VM Mods tape, but my own copy got dumped in some move > down the years. Wish I had it now, it would go really nicely on Herc. re: http://www.garlic.com/~lynn/2010d.html#79 LPARs: More or Less? the stuff done on csc/vm ... that leaked out to at&t, had been about the same time ... slightly eariler. the design of the shadow page tables followed the semantics for the hardware "look-aside buffer". the virtual machine has page tables that translate virtual addresses to what it thinks are real addresses. However, these are actually virtual addresses for the virtual machine. So when VM runs a virtual machine ... in virtual memory mode ... it is actually run with "shadow page tables". Shadow page table entries start out all invalid. The virtual machine immediately page faults, vm then has to look at the (virtual) page tables (in virtual machine) to translate from the virtual memory address to the virtual machine address ... vm then looks it its page table to translate from the virtual machine address to the real machine address. It is this "real machine address" that is placed into the shadow tables. The early, low & mid range 370s had a single STO stack ... everytime there was a change in the virtual address space pointer ... the hardware lookaside buffer was cleared and all entries invalidated. Early VM370's shadow table operation had similar design, single STO stack, everytime the virtual machine changed virtual address space pointer, all the shadow page table entries were cleared and invalidated. Moving from SVS to MVS significantly aggrevated this ... because MVS was changing virtual address space pointer at the drop of the hat (and vm370 was going thru massive overhead constantly invalidating the shadow page tables everytime MVS reloaded CR1). 370/168 had a 7-entry STO stack. There was a seven entry LRU queue of the most recently used STO values. Each hardware look-aside buffer entry had a 3-bit tag ... it was either one of the 7 currently valid STO entries ... or invalid. MVS constant reloading/changing CR1 was mitigated on real 168 with the 7-entry STO stack (loading new value into CR1 didn't do anything if the value was already one of the seven values in the STO staok). It wasn't until vm370 release 5 with HPO option that vm370 finally shipped something equivalent to multiple STO-stack (i.e. multiple shadow page tables being kept for a single virtual machine ... to try and minimize having to constantly clear all shadow page table entries every time MVS fiddled with CR1). The demise of FS saw a big need to get products back into the 370 product pipeline quickly. 3033 was such effort ... take the 370/168 logic and remap it to slightly faster chips. There was also some activity to introduce some purely MVS microcode performance assists on 3033 ... one such involved cross-memory services. One of the issues with 3033 and cross-memory services ... was the 3033 still had the 370/168 design with 7-entry STO stack ... and cross-memory services was significantly increasing the number of STOs being used ... overrunning the seven entries ... with corresponding big increase in look-aside buffer entry flushing (which netted out to worse performance; somewhat analogous to the shadow page table flushing that VM was constantly being forced to do). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
