[email protected] (Tim Zielke) writes: > 4. (Nth time load of a load module into the system by secondary > address space B) When loading the module into the virtual address > space B and physical memory, make sure any virtual pages for the load > module that do not need to be altered for B and were not altered for A > point to the same physical frame. These "shared" virtual pages for B > will also be marked as copy-on-write. Any future writes to these > "shared" virtual pages in address space B will result in B getting its > own separate physical frame.
re: http://www.garlic.com/~lynn/2014i.html#66 z/OS physical memory usage with multiple copies of same load module at different virtual addresses http://www.garlic.com/~lynn/2014i.html#67 z/OS physical memory usage with multiple copies of same load module at different virtual addresses http://www.garlic.com/~lynn/2014i.html#68 z/OS physical memory usage with multiple copies of same load module at different virtual addresses http://www.garlic.com/~lynn/2014i.html#71 z/OS physical memory usage with multiple copies of same load module at different virtual addresses the original 370 architecture had r/o protect for shared segments ... however retrofitting virtual memory to 370/165 ran into difficulty and was going to slip virtual memory announce by 6months. a suggestion was made that r/o protect and some other features be dropped to simplify things for the 370/165 implementation. the POK favorite son operating system said they had no reason to use such features. however, it resulted in enormous problems for vm370/cms which was already implemented to use it. as a result of decision to drop protection for shared pages ... vm370/cms had to do an ugly hack were it fiddled storage protect keys and psw key for the virtual machine (shared pages became key zero, all other pages became key "F" and the virtual machine psw always ran with key "F"). cms kernel had a single 64kbyte shared segment. during the FS period, I continued to work on 360/370 ... first cp67 and then moved over to vm370 (and would periodically ridicule the FS stuff). some old email about move from cp67 to vm370 http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 this included a cms paged mapped filesystem and greatly expanding sharing ... to any file object (not restricted to executables) could be designated r/o sharing. with the failure of FS, there was mad rush to get stuff back into the 370 product pipelines ... which contributed to decision to pick up stuff I had been been doing and include in product release ... including significantly extending sharing (past the original 64kbytes of the kernel) ... i had modify various pieces of CMS code so that it could run as r/o shared. However, the full page-mapped filesystem wasn't released ... in large part because of the bad reputation that FS "single-level-store" had acquired (although I frequently pointed out that I had learned what not to do based on what I had seen in tss/360, while FS just repeated all the same mistakes). In any case, a drastic subset of the sharing was picked up for VM370 release 3 w/o the paged-mapped filesystem, substituting a hack to the early named system support. However, this did greatly increase the number of shared pages that might be active at any one point. There was some other independent work that was also scheduled for vm370 release 3. VM370 VMA microcode assist came out for vm370 release 2, which directly simulated some number of priviledged instructions in virtual machine mode (w/o having priviledged interrupt into vm370 kernel for simulation). However it could be used by CMS virtual machines running shared segments ... because the VMA implemenation of LPSW, ISK, SSK instructions didn't account for the storage key shared paged protection hack. Somebody did a "copy-on-write" for CMS shared pages ... instead of the storage-key hack ... virtual machine was dispatched w/o shared page protection. however, before vm370 did task switch, if the previous executing virtual machine was running shared pages, each of the pages were checked for changed/modified bit, if found, the page was "unshared", aka copy-on-write, given to the virtual machine and nonchanged version scheduled for refresh from disk. CMS shared paged virtual machines could now be dispatched with VMA (since the storage protect hack was no-longer being used) ... reducing vm370 overhead ... at the cost of checking 16 shared pages on each task switch ... a net performance win. The conflict that came together for releasing the "copy-on-write" hack at the same time as significantly increasing shared pages was the VMA trade-off with shareg page checking didn't work when more than 16 pages had to be checked (normal CMS would now have minimum of 32 shared pages, and frequently a lot more). However, some salesman had pre-announced that VM370/CMS release 3 could use VMA to some of the large CMS-intensive customers ... who then had purchased the VMA feature (during the FS period and lack of 370 products, sales was frequently hard pressed to generate any revenue at all). The claim was that even tho the trade-off was no longer valid, they still had to ship CMS use of VMA because they couldn't tell those customers that they paid for something that wouldn't be used. Things got worse for VM370 release 4 which added SMP multiprocessor support. The VMA unprotected shared page hack for release 3 was dependent on only single task accessing a shared page at any moment (and fixup before anybody else accessed the same pages, since only a single virtual machine ran at a time). In VM370 release 4, (2-way SMP) it became worse because two virtual machines could be running simultaneously. As a result, two sets of shared virtual pages were required (one for each processor) ... and before dispatching a CMS virtual machine, its virtual memory tables had to be swizzled to point to the shared pages specific to the processor it would run on). One of my hobbies was doing enhanced production operation systems for internal datacenters ... and a long time customers was the world-wide sales&marketing online HONE system. HONE was one of the first to install CMS shared segment enhancements for APL executable (vm370 release 2 ... long before DWSS in release 3). However, I also continued to provided them with implementation of the storage key protection hack. When they were expanding to the largest single-system-image in the world ... I provided them release 3 vm370 with SMP multiprocessor support ... so all the processor complexes in the loosely coupled complex could also be multiprocessor (and still use the storage key protection). The HONE production APL environment included a large amount of APL code that was always active in every workspace. Since APL code was interpreted, there is some similarity between it and some of JAVA discussion ... and early HONE hack was to move large amounts of HONE common APL code into shared pages. Initially this was one-off specific for the HONE common APL code (bascially appended to executable image). However, this is old email with APL developer about generalizing APL to support any workspace load from CMS paged-mapped filesystem as "shared" (and position/address independent) http://www.garlic.com/~lynn/2006o.html#email821104 past posts mentioning HONE http://www.garlic.com/~lynn/subtopic.html#hone and other old email about fulist/browse/ios3270 in shared pages http://www.garlic.com/~lynn/2001f.html#email781010 http://www.garlic.com/~lynn/2001f.html#email781011 -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
