virtual memory 4495

Brian Inglis

Lynn's exposition is not always easy (at least for me) to follow completely, but his expansion on this topic in other posts (see, for reference therein)seems to suggest 1) that the grenoble implementation implemented only static (fixed-size) working sets and 2) that his implementation, while global in nature, *also* involved something resembling working sets (and something he called 'dynamic adaptive thrashing control').

If either of those was the case (or if the systems differed in other significant respects - since his tweaks seem to have tended to be fairly pervasive), then his observations about the relative performance of those two implementations really aren't applicable to a discussion of contemporary (more mature) working-set implementations.

Not in a manner which stressed the systems sufficiently to give any relative indication of their performance.

Of course, 'large' caches almost by definition are relatively insensitive to replacement policies anyway (according to studies using real access traces rather than academic intuition, I might add): it's when memory starts to get tight that the policy choices start to matter.

And there are considerably more applicable analogies than to microkernels to consider: those other situations where limiting the degree of multiprogramming in order to avoid thrashing has proven desirable (limits on numbers of concurrent and potentially interacting threads in server processes, limits on promiscuous numbers of concurrent and potentially interacting transactions in databases, cache-segmentation to avoid pollution by large sequential access streams, etc.). Whenever a resource is constrained, attempts to avoid hogging and-or contending for it unnecessarily are appropriate - and adaptive working-set approaches do exactly that by biasing process residencies to what each process needs to execute reasonably rather than allowing some subset of promiscuously-paging processes to bring the entire system to a crawl.

Furthermore, batch-evicting modified pages LRU for a single process increases the probability that batching them back in will be profitable - which of course is an absolute win which would be at best awkward to accomplish in a strictly global LRU approach (you'd have to evict a large enough group of pages at once to hit processes multiple times so that their dirty pages could be grouped, though if the mechanism were only pseudo-LRU such that lifetimes were relatively coarse-grained that might work).

I'd be interested in any serious studies (using real and of course repeatable system traces) of relative page-replacement policies (rather than random opinions and anecdotes) should you or anyone else have any at your finger tips.

- bill