glen herrmannsfeldt <[email protected]> writes: > It would seem less likely that they would use the exact same > replacement algorithm, but could eventually lock, anyway.
re: http://www.garlic.com/~lynn/2012b.html#98 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#16 5 Byte Device Addresses? "least recently used" is well studied characteristic ... that says that of all the current virtual pages ... the current least recently used page is the least likely to be used in the future. since the least recently used page is the least likely to be used in the future it becomes the basis for "LRU replacement algorithms" ... trying to select the least likely to be used page (based on being the least recently used). so lots of systems have implemented LRU replacement algorithms based on well studied program behavior ... although they all may have slightly different code implementations ... they would tend to select approximately the same virtual page for replacement. so running a "LRU strategy" under a "LRU strategy" ... vm370 will look at all the virtual machine pages and select the least recently used for replacement. The guest operating system will be looking at all its virtual pages and select the least recently used for replacement. The issue is that the guest virtual page that is selected for replacement occupies a guest virtual machine page ... and useage patterns are based on the same criteria. The result is vm370 will remove/replace a virtual machine page when it hasn't been used while the guest operating system will select the contents of the same virtual machine page for its replacement and start using that same virtual machine page with a different guest operating system virtual page. The effect is from the vm370 stand-point, the guest operating system is violating all the studies that have shown that the least recently used (virtual machine) virtual page is the least likely to be used in the future (because the guest operating system wants to select that same virtual machine page for use for replacement). There are other ways of treaking the algorithms. Lots of the AOS protype stuff for what would become OS/VS2 SVS came from cp67 ... like cp67's channel program translator, "CCWTRANS" was cobbled into the side of EXCP processing. However the POK performance group came up with a tweak for SVS LRU-replacement algorithm, before it first shipped. They observed if they selected/replaced "non-changed" LRU pages before "changed" pages ... they wouldn't first have to write the current virtual page to disk before being able to fetch the replacement page into the location. I argued strongly against it since it significantly distorted the LRU relationship ... but they went ahead anyway. Well late into the MVS release cycle, they "discovered" that the strategy resulted in choosing for replacement; higher-use, shared, non-changed linkpack virtual pages before lower-use, non-shared, private, changed application specific virtual pages. The cast had changed in POK and new people got awards for fixing the earlier work having done it wrong ... and somebody eventually contacted me if something similar could be fixed in vm370. My reply was that I had never done it that way since I was undergraduate in the 60s. lots of past posts mentioning virtual memory management and page replacement algorithms http://www.garlic.com/~lynn/subtopic.html#clock My 60s undergraduate work got me sucked into an academic uproar ... Jim Gray had left for Tandem but at 14-16Dec1981 ACM SIGOPS meeting asked me if I could lend a hand with somebody trying to get their Stanford PHD. It involved an area that I had originally worked on as undergraduate in the 60s. I had done something different than what was being done in the academic circles in the 60s. The primary person behind the 60s academic work was violently objecting to the Stanford PHD being awarded (because it was in conflict with his work). My work was being shipped in cp67. However, in the early 70s, the Grenoble Science Center had modified their version of cp67 to correspond with the 60s academic strategy. The Cambridge Science Center 360/67 with 768k memory (104 pageable pages after fixed kernel storage requirements) with my strategy gave about the same performance with 80 users as the Genoble Sicence Center 360/67 with 1mbyte memory (154 pageable pages after fixed kernel storage requirements) with 35 users (almost identical workloads). CSC 360/67, with my strategy could support approx. twice the number of users as GCS 360/67 with the academic strategy (and 50% more pageable storage). It was possibly the only direct apples-to-apples comparison of my strategy and the 60s academic strategy. Past post on the subject http://www.garlic.com/~lynn/2006w.html#46 the above contains this response that I was finally allowed to send nearly a year later (after the request at ACM SIGOPS) http://www.garlic.com/~lynn/2006w.html#email821019 I prefer to think that the delay in allowing me to send the response was part of general corporate punishment that I was getting as being blamed for online computer conferncing on the internal network in the late 70s and early 80s ... as opposed to the corporation taking sides in the academic dispute. from ibm jargon: Tandem Memos - n. Something constructive but hard to control; a fresh of breath air (sic). That's another Tandem Memos. A phrase to worry middle management. It refers to the computer-based conference (widely distributed in 1981) in which many technical personnel expressed dissatisfaction with the tools available to them at that time, and also constructively criticised the way products were are developed. The memos are required reading for anyone with a serious interest in quality products. If you have not seen the memos, try reading the November 1981 Datamation summary. ... snip ... folklore is that when the executive committee (chairman, ceo, pres, etc) was informed about online computer conferencing (and the internal network), five-of-six wanted to fire me. misc. past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet -- 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
