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
similar?
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 <buhr@stat.wisc.edu>