Messages in this thread | ![/](/images/icornerl.gif) | | Subject | generic aging layer on top of slab allocator? (was Re: PATCH to pre-patch-2.1.45: clean_inode needs to reset i_writecount) | From | (Kevin Buhr) | Date | 10 Jul 1997 19:06:00 -0500 |
| |
Linus Torvalds <torvalds@transmeta.com> 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 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>
| ![\](/images/icornerr.gif) |