lkml.org 
[lkml]   [1997]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subjectgeneric aging layer on top of slab allocator? (was Re: PATCH to pre-patch-2.1.45: clean_inode needs to reset i_writecount)
From
Date
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>

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.038 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site