Re: SLUB defrag pull request?

[Eric Dumazet]

Christoph Lameter a écrit :
> On Thu, 23 Oct 2008, Pekka Enberg wrote:
>
> > > The problem looks like its freeing objects on a different processor that
> > > where it was used last. With the pointer array it is only necessary 
> > > to touch
> > > the objects that contain the arrays.
> >
> > Interesting. SLAB gets away with this because of per-cpu caches or
> > because it uses the bufctls instead of a freelist?
>
> Exactly. Slab adds a special management structure to each slab page that 
> contains the freelist and other stuff. Freeing first occurs to a per cpu 
> queue that contains an array of pointers. Then later the objects are 
> moved from the pointer array into the management structure for the slab.
>
> What we could do for SLUB is to generate a linked list of pointer arrays 
> in the free objects of a slab page. If all objects are allocated then no 
> pointer array is needed. The first object freed would become the first 
> pointer array. If that is found to be exhausted then the object 
> currently being freed is becoming the next pointer array and we put a 
> link to the old one into the object as well.

This idea is very nice, especially considering that many objects are freed
by RCU, and their rcu_head (which is hot at kfree() time), might be far
away the linked list anchor actually used in SLUB.

At alloc time, I remember I added a prefetchw() call in SLAB in __cache_alloc(),
this could explain some differences between SLUB and SLAB too, since SLAB
gives a hint to processor to warm its cache.




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