Messages in this thread | | | Date | Fri, 10 Jul 1998 00:37:47 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: cp file /dev/zero <-> cache [was Re: increasing page size] |
| |
Hi,
On Thu, 9 Jul 1998 20:59:57 +0200 (CEST), Rik van Riel <H.H.vanRiel@phys.uu.nl> said:
> On Thu, 9 Jul 1998, Stephen C. Tweedie wrote: >> >> There's a fundamentally nice property about the multi-level cache >> which we _cannot_ easily emulate with page aging, and that is the >> ability to avoid aging any hot pages at all while we are just >> consuming cold pages.
> Then I'd better incorporate a design for this in the zone > allocator (we could add this to the page_struct, but in > the zone_struct we can make a nice bitmap of it).
It's nothing to do with the allocator per se; it's really a different solution to a different problem. That helps, actually, as it means we're not forced to stick with one allocator if we want to use such a scheme.
> OTOH, is it really _that_ much different from an aging > scheme with an initial age of 1?
Yes, it is: the aging scheme pretty much forces us to age all pages on an equal basis, so a lot of transient pages hitting the cache has the side effect of prematurely aging and evicting a lot of existing, potentially far more valuable pages. A multilevel cache is pretty much essential if you're going to let any cached data survive a grep flood. Whether you _want_ that, or whether you'd rather just let the cache drain and repopulate it after the IO has calmed, is a different question; there are situations where one or other decision might be best, so it's not a guaranteed win. But the multilevel cache does have some nice properties which aren't so easy to get with page aging. It also tends to be faster at finding pages to evict, since we don't require multiple passes to flush the transient page queue.
--Stephen.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |