Hey, maybe we need a new config variable:
CONFIG_I_HAVE_512_GIGS_OF_RAM_BUT_DISKS_BUILT_IN_THE_1940S
> I certainly agree that it might be something interesting to look into. At
> the same time I'm a bit nervous about trying to be too generic - in many
> cases we can know what kinds of allocation patterns certain objects have,
> and maybe do a better job by having a specialized garbage-collector that
> has innate knowledge of what it is working with.
Actually, in retrospect, what I was thinking of breaks down into two
distinct schemes: one, a generic cache aging toolkit that sounds like
what Thomas is working on; and two, some sort of clean mechanism for
hooking a custom aging function (written with or without the generic
aging toolkit) into the allocator, as an alternative to adding
function calls to the loop in "do_try_to_free_page".
Without this second part, we sometimes end up doing aging at "funny
times" (i.e., aging from some arbitrary function that we think/hope
will get called on a regular basis), when we should usually be doing
aging when we actually need memory for something.
Anyway, I think I'll wait for your dentry aging code and try to use it
as a starting point for a "proof of concept".
Thanks!
Kevin <buhr@stat.wisc.edu>