lkml.org 
[lkml]   [2007]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH] SLUB use cmpxchg_local
    * Christoph Lameter (clameter@sgi.com) wrote:
    > On Tue, 21 Aug 2007, Mathieu Desnoyers wrote:
    >
    > > - Fixed an erroneous test in slab_free() (logic was flipped from the
    > > original code when testing for slow path. It explains the wrong
    > > numbers you have with big free).
    >
    > If you look at the numbers that I posted earlier then you will see that
    > even the measurements without free were not up to par.
    >

    I seem to get a clear performance improvement in the kmalloc fast path.

    > > It applies on top of the
    > > "SLUB Use cmpxchg() everywhere" patch.
    >
    > Which one is that?
    >

    This one:


    SLUB Use cmpxchg() everywhere.

    It applies to "SLUB: Single atomic instruction alloc/free using
    cmpxchg".

    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
    ---
    mm/slub.c | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    Index: slab/mm/slub.c
    ===================================================================
    --- slab.orig/mm/slub.c 2007-08-20 18:42:16.000000000 -0400
    +++ slab/mm/slub.c 2007-08-20 18:42:28.000000000 -0400
    @@ -1682,7 +1682,7 @@ redo:

    object[c->offset] = freelist;

    - if (unlikely(cmpxchg_local(&c->freelist, freelist, object) != freelist))
    + if (unlikely(cmpxchg(&c->freelist, freelist, object) != freelist))
    goto redo;
    return;
    slow:
    > > | slab.git HEAD slub (min-max) | cmpxchg_local slub
    > > kmalloc(8) | 190 - 201 | 83
    > > kfree(8) | 351 - 351 | 363
    > > kmalloc(64) | 224 - 245 | 115
    > > kfree(64) | 389 - 394 | 397
    > > kmalloc(16384)| 713 - 741 | 724
    > > kfree(16384) | 843 - 856 | 843
    > >
    > > Therefore, there seems to be a repeatable gain on the kmalloc fast path
    > > (more than twice faster). No significant performance hit for the kfree
    > > case, but no gain neither, same for large kmalloc, as expected.
    >
    > There is a consistent loss on slab_free it seems. The 16k numbers are
    > irrelevant since we do not use slab_alloc/slab_free due to the direct pass
    > through patch but call the page allocator directly. That also explains
    > that there is no loss there.
    >

    Yes. slab_free in these tests falls mostly into __slab_free() slow path
    (I instrumented the number of slow and fast path to get this). The small
    performance hit (~10 cycles) can be explained by the added
    preempt_disable()/preempt_enable().

    > The kmalloc numbers look encouraging. I will check to see if I can
    > reproduce it once I sort out the patches.

    Ok.

    --
    Mathieu Desnoyers
    Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
    -
    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: 2007-08-22 01:15    [W:0.026 / U:215.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site