Re: SLUB defrag pull request?

[Eric Dumazet <dada1@cosmosbay.com>]

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.