Re: generic aging layer on top of slab allocator? (was Re: PATCH to pre-patch-2.1.45: clean_inode n

Kevin Buhr (
10 Jul 1997 19:40:03 -0500

Linus Torvalds <> writes:
> (you can just consider the current behaviour as
> _extremely_ aggressive caching ;)

Hey, maybe we need a new config variable:


> 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".


Kevin <>