Re: [RFC 0/4] Object reclaim via the slab allocator V1

[Christoph Lameter]

On Wed, 28 Jun 2006, Andrew Morton wrote:

> > 2. A destructor was provided during kmem_cache_create().
> >    If SLAB_DTOR_FREE is passed in the flags of the destructor
> >    then a best effort attempt will be made to free that object.
> > 
> 
> It would be better to make the higher-level code register callbacks for
> this sort of thing.  That code knows how to determine if an object is
> freeable, can manage aging info, etc.

The destructor is such a callback.

> > For slab we check all the objects in the slab. If all object have
> > a refcount of one then we free all the objects and return the pages of the
> > object to the page allocator.
> 
> That seems like quite a drawback.  A single refcount=2 object on the page
> means that nothing gets freed from that page at all.  It'd be easy
> (especially with dcache) to do tons of work without achieving anything.

We will always reclaim a few object from each page. See the patch.

Single refcount=2 objects could also be detected and we could try to free 
them.

> a) compact dentries by copying them around or, perhaps,

Since we free some dentries in each block they will be effectively be 
moved because they get reallocated in a current slab block.

> b) make dentry reclaim be guided by the dcache tree: do a bottom-up
>    reclaim, or a top-down reclaim when we hit a directory, etc.  Something
>    which understands the graph rather than the plain global LRU.

The callback can make that determination and could trigger these events.
The callback notifies the higher layers that it would be advantageous to 
free this element. The higher layers can then analyze the situation and 
either free or give up.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/