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
