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

[Christoph Lameter <clameter@sgi.com>]

On Wed, 28 Jun 2006, Andrew Morton wrote:

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

Is that such a problem? It reduces the amount of indirect function calls 
needed.

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

Right. If we could directly migrate objects then it would be faster. Think 
about this as swap migration. Later we can get more sophisticated.

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

The reference counter can be used to insure that the object is not freed.

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

Right. I am not clear on how exactly to do that. These actions would need 
to be particular to an object type. I just dealt with the slab 
side of things and I think this is the bare minimum to get us started 
along this road.

Got an enhanced version of it here but this is all not ready for prime 
time and needs some more thought. Maybe we can talk about it in Ottawa.

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