Once again, thank you once again Anne and Lynn, and Mike Myers too. Nice to hear from you again, Mike.
Only wished I knew all this back when we were trying to figure out how things worked. If only IBM would have made people like you available to the outside world. We had to read between the lines and that does not always yield the best results. On Mon, Feb 22, 2010 at 11:46 AM, Anne & Lynn Wheeler <l...@garlic.com>wrote: > The following message is a courtesy copy of an article > that has been posted to bit.listserv.ibm-main,alt.folklore.computers as > well. > > > gahe...@gmail.com (George Henke) writes: > > This was to facilitate performance for VM/MVS shops because there was no > > comparable VM/VSE feature for MVS and VM to control the handshaking > between > > the two > > > > The entire MVS virtual machine would get swapped out whenever an MVS > address > > space, eg TSO user, batch, was swapped out. > > it wasn't that the MVS virtual machine got swapped, when there was a > virtual machine page fault; it was that the virtual machine was > non-dispatchable (didn't execute) while the (virtual machine) page fault > was being serviced. > > the issue with VM/VS1 handshaking (actually there had been a earlier > implementation at univ. with MVT handshaking) was when the virtual > machine had a page fault ... the virtual machine was made non-executable > while the page fault was being serviced. > > Part of VS1 (and earlier MVT) handshaking ... was there was one-for-one > mapping between VS1 page and the virtual machine page (in VS1 case, VS1 > had single virtual address space ... somewhat like SVS ... and in > handshaking, there was a one-for-one mapping between the VS1 virtual > address space definition and the virtual machine address space). In any > case, since all virtual pages "appeared" to be resident and VS1 would > never have its own page fault. > > In any case, the virtual machine could have a page fault (at the VM > level) and be non-executable while the page fault was being handled. > The VM/VS1 handshaking would reflect a "psuedo" (virtual machine) page > fault to the VS1 operating system ... allowing VS1 to task switch to > some other task (in VS1). If there was nothing else to execute ... then > VS1 would enter wait-state ... until VM had serviced the page fault (aka > there was not "swapping" ... it was just whether the virtual machine was > dispatchable or not). This allowed the virtual guest to have a higher > degree of multitasking (virtual guest overlapping execution of other > tasks while VM serviced a page fault). > > Part of the issue was that VM performed paging operations significantly > more efficiently than VS1 (I had done much shorter pathlength as well as > a better page replacement algorithm) ... and so VS1 could have higher > thruput in virtual machine environment (once handshaking allowed VS1 to > continue to execute while VM was servicing a page fault). > > There were other issues with virtual memory paging operations. VM's page > replacement algorithm tends to approximate LRU (least recently used). > Most of the guest operating systems (when they are doing paging) also > tend to have page replacement algorithm that approximates LRU. There is > a pathelogical scenario if both the virtual guest is taking page faults > and VM is taking page faults ... that VM will select a virtual guest > page that currently isn't be used (LRU) to be replaced ... and the same > time that the virtual guest (possibly MVS) has decided that it wants to > use that corresponding page (since it also decides that the current > contents of the page isn't being used). The line I used is LRU > algorithms tend not to be recursively friendly (i.e. running an virtual > LRU algorithm in a virtual machine environment running an LRU algorithm > can result in exactly the wrong page being chosen). misc. past posts > about page replacement algorithms > http://www.garlic.com/~lynn/subtopic.html#wsclock > > Another piece of trivia ... in the original transition from MVT to SVS > and their page replacement algorithm ... I got into argument that they > were doing some tweaks to their implementation that would do exactly the > wrong thing. That implementation continued well into the MVS release > cycle ... when it finally dawned on them that they would select > high-use, shared, R/O linkpak pages for replacement before lower-use, > private, R/W data pages. > > Originally (VS1) handshaking was in the time-frame when Endicott had > also done the VM ECPS microcode assist for 138/148 ... and was trying to > convince the corporation that 138/148 (and later 43xx) would be shipped > as VM-only machines (somewhat like LPAR capability is shipped on all > machines today). Unfortunately, at the same time POK was trying to > convince corporate that vm370 should be killed off (in part because POK > wanted all the people in the vm370 development group to be moved to POK > to support MVS/XA development) ... so corporate never agreed to 138/148 > being "vm-only". old post about methology used for creating ECSP > microcode assist: > http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist > > the basis guideline was that we were told that the machines had 6kbytes > of microcode space available ... and to choose the pieces that would > give the biggest bang-for-the-buck. > > "E" was the low-end/mid-range architecture ... analogous to "XA" > architecture that POK had done (primarily for MVS) ... old email ref > > Date: 09/16/82 08:31:14 > From: wheeler > > re: e-architecture; E-architecture is the internal name for the 370 > architecture extension that came out with the (original) 4300 series > machines. It is supported by VS1E & DOS/VSE. It's primary feature is it > moves the equivalent of the page & swap tables to below the microcode > interface. There are new instructions to validate, connect, invalidate, > & disconnect page frames. This architecture was developed primarily by > Germany during the middle 70s & basicly is an attempt to move > "troublesome" pieces (for DOS) of the system down into the hardware. > > XA architecture is a completely different architecture extension. It was > developed in POK and primarily represents their (similar) goal to > migrate "troublesome" pieces of MVS down into the hardware ... giving > the hardware engineers opportunities to solve MVS system problems that > the MVS software programmers have found difficult to deal with. > > Note that 4300s primarily run in 370 mode. > > ... snip ... > > other old email discussiong 43xx > http://www.garlic.com/~lynn/lhwemail.html#43xx > > -- > 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 > -- George Henke (C) 845 401 5614 ---------------------------------------------------------------------- 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
