The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Veilleux, Jon L) writes: > In z/OS 1.8 the memory management is much more conducive to large > memory. They no longer use the least recently used algorithm and no > longer check every page. This has made a big difference for us. Under > 1.7 we had issues with large real memory sizes due to the constant > checking by RSM. This is no longer the case and we have increased our > memory dramatically with no performance hit. one of the things found in "clock" LRU-approximation that i had originally done as undergraduate in the 60s http://www.garlic.com/~lynn/subtopic.html#wsclock was that if the interval between page resets started to exceed some limit, then there was little differention benefit of the reset activity ... least recently used tends to have some implicit dependencies on amount of "history" ... if the duration is too long ... then it lost much of its correlation being able to differentate between pages as to future page reference pattern. however across a wide range of configurations and workloads in the 70s, "clock" LRU-approximation had the advantage of effectively being able to (usefully) dynamically adapt the interval. however with a lot of cp67 experimenting and also heavy use of storage reference traces and page replacement modeling ... it was possible to show that outside some useful operating range ... the use of LRU algorithms for differentiating/predicting future page reference behavior became less and less accurate. It was also possible to show that for very large memories ... that the overhead of repeatedly resetting page reference bits provided less benefit than any possible improvement in page replacement strategy. we did do some experimenting at the science center attempting to recognize the operating region/environment across where clock LRU-approximated was beneficial ... and attempt to take some secondary measures/strategies when it was outside that operating region/envrionment. one of the scenarios was that most LRU-approximation algorithms are measured against how well they performed vis-a-vis simulation that exactly implemented least-recently-used page ordering (measured in terms of total page faults for given workload and real storage size). "Good" approximations tended to come within 5-15 percent (total page faults) of "real" least-recently-used page ordering. We were able to find some page replacement variations that instead of being 5-15 percent worse/more (total page faults compared to simulated "real" least-recently-used page ordering), we were able to show 5-15 percent fewer total page faults. the scenario was that in some configuration/workload scenarios, LRU-approximate could effectively cycle thru every page in real storage w/o finding a candidate ... and then take the first page it started with. Besides having a lot of processing overhead, this characteristic effectively degraded to FIFO page replacement (there are operating regions for LRU where it can degenerate to FIFO page replacement at the same time taking an extrodinary amount of processor overhead). our variation tended to recognize when operating in this configuration/workload region and effectively switched to RANDOM page replacement at very low processor overhead (and modeling showed that when not able to make any other differentiation between pages to be replaced ... RANDOM replacement makes better choice than FIFO, independent of the overhead issue). In fact, the original cp67 delivered at the univ. last week jan68, ... also referenced here http://www.garlic.com/~lynn/2007r.html#74 System 360 EBCDIC vs. ASCII ... effectively implemented something that tended to operate as FIFO replacement with purely software and didn't make use of the hardware reference bits. As undergraduate, I did the kernel algorithm and software changes to implement "clock" LRU-approximation page replacement ... taking advantage of page replacement bits. In this scenario ... with only on the order of 120 real "pageable pages" ... this reduced the time spent in page replacement selection (under relatively heavy load) from approx. 10 percent of total processor to effectively unmeasureable (and at the same time drastically improvement the quality of the replacement choice). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
