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


On 10 Jul 1997, Kevin Buhr wrote:
>
> 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?

I was thinking of making the dentry stuff look pretty much the same as the
current inode allocation/deallocation. At least for the first version. I
suspect that we'll need better LRU-type replacement at some point, but for
various reasons it is actually better to start off with something that is
likely to throw away dentries too easily rather than one that tries to
cache the aggressively (you can just consider the current behaviour as
_extremely_ aggressive caching ;)

The reason I want to throw out dentries quickly is that it will show up
any potential race conditions a lot more clearly.

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

Thomas Schoebel has been looking into a generic kind of "hashed cache with
aging", because a lot of kernel problems tend to fall into that category.

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.

Linus


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