virtual memory 4473

ref:

I posted it numerous times before ... so there were URLs to where it had been repeatedly posted before

basically i had done local LRU. cambridge had 768kbyte 360-67, 104 "pageable pages" after fixed kernel requirements running cp67.

grenoble modified they same cp67 for "working set" dispatcher and local LRU running on 1mbyte 360-67, 154 "pageable pages" after fixed kernel requirements (basically 50 percent more real storage for application paging). they published a paper on the work in the early 70s in cacm

J. Rodriquez-Rosell, The design, implementation, and evaluation of a working set dispatcher, cacm16, apr73

basically running same kind of workload, cambridge ran approx. 80 users with the same interactive response and thruput as grenoble did with 35 users i.e. cambridge system with 1-3rd less real storage for application paging was able to support more than twice as many users with comperable thruput and no worse interactive response ... typically much better. the interactive response was somewhat more sensitive to latency buttociated with the "working dispatcher" attempting to avoid page thrashing and how effective local LRU was in selecting pages for replacement ... so the cambridge system response ... even with more than twice as many users typically had better interactive response and lower latency delays.

specific reference from the earlier listed "grenoble" references

after all the festuche had settled, the stanford phd on clock and global lru was finally awarded ... despite the best efforts by some of the backers of local LRU.

consistent with the stuff I had invented as an undergraduate in the 60s ... also, about the time the whole uproar was going on over whether somebody would get a stanford phd thesis on global LRU ... we had a project that was recording all disk record references from a variety of operational production systems.

there were also a fairly sophisticated cache simulator built which was looking at various disk i-o caching strategies. simulation was done for a broad range of different configurations, disk arm caching, controller caching, channel caching, system caching, etc. across the broad range of different environments and workloads, it was found for a given amount of electronic storage ... system level caching always provided better throughput (modulo some issues with use of some disk arm store for rotational delay compensation ... i.e. being able to start i-o transfer as soon the head had settled as opposed to waiting for the records to arrive under the head in a specified sequence). if there was a fixed amount of electronic cache ... say 20mbytes ... using that 20mbytes for a system level cache always provided better thruput than breaking the electronic store up and parbreastioining it out to any level of sub-components.

parbreastioning the electronic store and parceling it out to subcomponents is analogous to doing local LRU replacement strategy (i.e. parbreastioning real memory and only doing replacement within the individual parbreastions).

aggregating the electronic store into a single larger cache is analogous to doing global LRU replacement strategy.

some past posts mentioning the global versus parbreastioned cache work:

and for some drift and urban legend

--