virtual memory 4494

in this previous incarnation of the thread-subject from 7aug2004

there was the issue of paging virtual memory being a flavor of cache managed by LRU-type replacement algorithms. besides the similarity between global-local LRU replacement and configuration decision about having fixed amount of electronic store as a single "system" global cache or parbreastioned and divided up into smaller caches dedicated to specific sub devices ... you can also get into the subject of cache hierarchies as well as technology limitations where you have lots of electronic store and for various issues that it can't all be applied to the highest level in the hierarchy (in which case still being able to use the available electronic storage at other levels in the infrastructure might still provide some benefit).

an example of the limitation issues was the 4.5mip 3033 processor versus a cluster of six 1mip 4341 processors. initially, all the real memory you could with either the 3033 or the 4341 was 16mbytes. six 1mip 4341 processors with 16mbytes of electronic store each (96mbytes total) cost about the same as a 4.5mip 3033 processor with 16mbytes (16mbytes total) .... buttuming the workload was parbreastionable in a cluster, the six 4341 cluster got much higher thruput than the single 3033 at about the same price.

the cache hiearchy could have other issues that I've referred to as the dup-no-up problem. circa 1981, you could get a 3880 disk controller with cache ... limited to 8mbytes. if came as a 3880-11-ironwood and cache line was 4k records or 3880-13-sheriff where cache line was full-track.

a 3033 or 3081 with 16mbytes real storage might have two such disk controllers in configuration for a total of 16mbytes of disk controller cache. the issue in the "duplicate" strategy was if every page fault by the processor pulled in a page from disk, thru the disk controller cache, a copy of the page would be resident in both the disk controller cache and the processor memory (i.e. there was a duplicate in both places). then what happens is when could there be a page that wasn't in the processor 16mbyte memory that happened to be in the disk cache? i.e. if the processor faulted on a virtual page (because it wasn't resident and needed to be brought in from disk), was there a reasonable probability that a page not in processor memory being found in the disk cache. if the total disk cache held about the same number of 4k records as the main processor memory and every record in processor memory was duplicated in disk cache ... what was the probability that there was a 4k record in disk cache that wasn't in processor memory.

I had actually started working on a resource management duplicate-no-duplicate strategy with page migration in configuration with a hierarchy of different performance paging devices (fixed-head 2305s and lots of moveable arm 3330 disks) in the 70s ... which was released as part of the resource manager on 11may1976 .. a couple

in the 3380-ii-ironwood scenario the processor page i-o could do reads that were "normal" (if it wasn't in the disk cache, it would be read into both disk cache and processor memory, if it was in disk cache, it would be read directly from cache) or "destructive" (if it was in the disk cache, it would be read from disk cache and deallocated from the cache ... aka destructive read; if it wasn't in disk cache, it would be read directly into processor memory w-o involving the cache).

misc. past posts mentioning duplicate-no-duplicate scenarios for hierarchical caches

misc. past posts mentioning the 3033-4341 parbreastioned comparison (implementation issues)

--