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

Kevin Buhr (
10 Jul 1997 19:06:00 -0500

Linus Torvalds <> writes:
> I haven't seen any corruption - the only problem I see these days is the
> memory leak due to not freeing dentries (I'm working on this), and the
> related dirty shutdown because we don't know that we can unmount.

Yeah, my machine just hums until the morning "updatedb". Then,
suddenly, performance isn't so hot. ;)

If you have time for a quick explanation, how are you planning to
implement dentry aging/freeing? Will there suddenly be a call to
"shrink_dcache" from "do_try_to_free_page"? Or will there be a
garbage collection threshold for the number of allocated dcaches with
actual collection triggered by allocation of a new dentry or something

On a related topic, it occurs to me that it might be nice to have
another layer sitting on top of the slab allocator to provide
reasonably generic aging support for the slab caches. Under this
scheme, "kmem_cache_reap" wouldn't just destruct slabs of free
objects; it would also use a set of cache-dependent functions to
locate and age "freeable" objects, so they'd eventually be
automagically freed (and the slabs destructed).

Then, anything that was implemented as a slab cache could elect to get
aged "for free" during "do_try_to_free_page" calls when memory was
actually needed. Somewhere down the road, we'd conceivably have *all*
cached data structures effectively held in a single, unified cache
(without a bunch of unsightly hooks in "do_try_to_free_page"), with
all relevant aging driven by the allocator.

Any thoughts?

Kevin <>