[lkml]   [2008]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 21/21] slab defrag: Obsolete SLAB

    On Wed, 2008-05-14 at 11:03 -0700, Christoph Lameter wrote:
    > On Wed, 14 May 2008, Andi Kleen wrote:
    > > iirc profiling analysis showed that the problem was the page lock
    > > serialization (in particular the slab_lock() in __slab_free). That
    > > was on
    > Do you have an URL?
    > > I think the problem is that this atomic operation thrashes cache lines
    > > around. Really counting cycles on instructions is not that interesting,
    > > but minimizing the cache thrashing is. And for that it looks like slub
    > > is worse.
    > It can thrash cachelines if objects from the same slab page are freed
    > simultaneously on multiple processors. That occurred in the hackbench
    > regression that we addressed with the dynamic configuration of slab sizes.
    hackbench regression is because of slow allocation instead of slow freeing.
    With dynamic configuration of slab sizes, fast allocation becomes 97% (the bad
    one is 68%), but fast free is always 8~9% with/without the patch.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2008-05-15 05:33    [W:0.327 / U:6.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site