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

[Andrew Morton]

On Wed, 28 Jun 2006 17:47:17 -0700 (PDT)
Christoph Lameter <clameter@xxxxxxx> wrote:

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

I was, of course, referring to the unpleasant requirement that the object
layout start with an atomic_t.


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

I read the description.

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

By performing a disk read.  That is not compaction - it is eviction.

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

How do you propose handling the locking?  dcache is passed a bare pointer
and no locks are held, but it is guaranteed that the object won't be freed
while it's playing with it?

If so, take dcache_lock and then validate the object's current state in
some manner?

-
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/