lkml.org 
[lkml]   [2008]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SLUB defrag pull request?
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@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: 2008-10-23 17:19    [W:0.400 / U:1.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site