Messages in this thread | | | Date | Thu, 23 Oct 2008 17:17:09 +0200 | From | Eric Dumazet <> | Subject | Re: 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/
| |