lkml.org 
[lkml]   [2006]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 0/4] Object reclaim via the slab allocator V1
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/

\
 
 \ /
  Last update: 2006-06-29 19:23    [from the cache]
©2003-2011 Jasper Spaans