lkml.org 
[lkml]   [2009]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH -v9][RFC] mutex: implement adaptive spinning
    From
    Date
    On Tue, 2009-01-13 at 18:21 +0100, Peter Zijlstra wrote:
    > On Tue, 2009-01-13 at 08:49 -0800, Linus Torvalds wrote:
    > >
    > > So do a v10, and ask people to test.
    >
    > ---
    > Subject: mutex: implement adaptive spinning
    > From: Peter Zijlstra <a.p.zijlstra@chello.nl>
    > Date: Mon Jan 12 14:01:47 CET 2009
    >
    > Change mutex contention behaviour such that it will sometimes busy wait on
    > acquisition - moving its behaviour closer to that of spinlocks.
    >

    I've spent a bunch of time on this one, and noticed earlier today that I
    still had bits of CONFIG_FTRACE compiling. I wasn't actually tracing
    anything, but it seems to have had a big performance hit.

    The bad news is the simple spin got much much faster, dbench 50 coming
    in at 1282MB/s instead of 580MB/s. (other benchmarks give similar
    results)

    v10 is better that not spinning, but its in the 5-10% range. So, I've
    been trying to find ways to close the gap, just to understand exactly
    where it is different.

    If I take out:
    /*
    * If there are pending waiters, join them.
    */
    if (!list_empty(&lock->wait_list))
    break;


    v10 pops dbench 50 up to 1800MB/s. The other tests soundly beat my
    spinning and aren't less fair. But clearly this isn't a good solution.

    I tried a few variations, like only checking the wait list once before
    looping, which helps some. Are there other suggestions on better tuning
    options?

    (I retested v7 and see similar results)

    -chris





    \
     
     \ /
      Last update: 2009-01-14 04:03    [W:0.025 / U:30.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site