glen herrmannsfeldt <g...@ugcs.caltech.edu> writes: > That is, as I understand it, pretty close to how it started out. > > Among others, though OS/VS1 has special features for running > under VM that OS/VS2 never got. It has the ability to switch > to a different task while VM is paging a task. That avoids > the double paging problem that otherwise occurs.
customers had previously made such changes to MVT ... which is possibly where at least the idea of the VS1 change. In OS/VS2 SVS it had single 16mbyte virtual memory laid out almost as if MVT running in 16mbyte real machine. When MVT ran in virtual machine ... when a virtual SIO was done ... CP67 would scan the virtual channel program and create a "shadow" copy with "real" addresses ... which would be the channel program that got executed. This routine from cp67 (ccwtrans) was cribbed into the side of EXCP processing ... i.e. with transition to virtual memory then all the OSes had the same issue with channel programs passed in EXCP ... needing creating nearly identical channel programs but with "real" addresses in place of virtual addresses. In OS/VS1 case, it had things laid out in a 4mbyte virtual address space (as if it was running on real 4mbyte machine). In the OS/VS1 handshaking case ... a 4mbyte virtual machine was created with OS/VS1 4mbyte virtual address space mapped one-for-one to the virtual machine address space. Whenever, vm370 had a os/vs1 virtual machine page fault ... if the machine was running in application (and not in os/vs1 kernel) ... vm370 would reflect special page fault to the virtual machine. OS/VS1 could then do task-switch as if it was a OS/VS1 application virtual page fault. Later when vm370 had fetched the OS/VS1 virtual machine virtual page ... vm370 would reflect a special interrupt to OS/VS1 (indicating the page was available). >From Melinda's "VM and the VM Community" http://web.me.com/melinda.varian/Site/Melinda_Varians_Home_Page.html Dewayne Hendricks reported at SHARE XLII, in March, 1974, that he had successfully implemented MVT-CP handshaking for page faulting, so that when MVT running under VM took a page fault, CP would allow MVT to dispatch another task while CP brought in the page. At the following SHARE, Dewayne did a presentation on further modifications, including support for SIOF and a memory-mapped job queue. With these changes, his system would allow multitasking guests actually to multitask when running in a virtual machine. Significantly, his modifications were available on the Waterloo Tape. ... and ... then was able to get MFT & MVT running faster under vm370 than it ran on "bare" machine By SHARE 49, Dewayne was able to state that, It is now generally understood that either MFT or MVT can run under VM/370 with relative batch throughput greater than 1." That is to say, they had both been made to run significantly faster under VM than on the bare hardware. Dewayne and others did similar work to improve the performance of DOS under VM. Other customers, notably Woody Garnett(122) and John Alvord, soon achieved excellent results with VS1 under VM. ... snip ... There is a separate issue with OS/VS2 (of any ilk) running under vm370 ... which is pathelogical case of a virtual memory operating system system managing with least recently algorithm in virtual machine which manages its virtual memory with least recently algorithm. The scenario is that a virtual machine page that hasn't been used for awhile ... is the virtual page that vm370 is likely to select for replacement/removal. However, the operating system in the virtual machine ... if it is also doing paging ... may also select the very same page to be the next one to use (after it has just been selected for removal). From a theoritical standpoint cascading LRU-algorithms will appear to violate least-recently-used replacement assumptions (i.e. a least-recently-used page can be the next most likely to be used rather than the least likely to be next used). This characteristic also exhibits itself with DBMS caches that are managed with LRU strategy when running in a virtual memory operating system that also manages with LRU strategy. The VS1 handshaking isn't actually a double paging issue ... that was handled by configuration of VS1's virtual address space the same as the virtual machine storage size. The handshaking worked with MVT&MFT as well as VS1 ... allowing the guest operating system to task switch while vm370 was handling page fault. more detailed discussion pg.25 vm/vs handshaking http://www.bitsavers.org/pdf/ibm/370/vm370/GC20-1800-6_VM370intr_Oct76.pdf -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
