lkml.org 
[lkml]   [2013]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v7 1/4] qrwlock: A queue read/write lock implementation
    From
    On Fri, Nov 22, 2013 at 11:04 AM, Waiman Long <Waiman.Long@hp.com> wrote:
    >
    > In term of single-thread performance (no contention), a 256K
    > lock/unlock loop was run on a 2.4GHz and 2.93Ghz Westmere x86-64
    > CPUs. The following table shows the average time (in ns) for a single
    > lock/unlock sequence (including the looping and timing overhead):
    >
    > Lock Type 2.4GHz 2.93GHz
    > --------- ------ -------
    > Ticket spinlock 14.9 12.3
    > Read lock 17.0 13.5
    > Write lock 17.0 13.5
    > Queue read lock 16.0 13.4
    > Queue write lock 9.2 7.8

    Can you verify for me that you re-did those numbers? Because it used
    to be that the fair queue write lock was slower than the numbers you
    now quote..

    Was the cost of the fair queue write lock purely in the extra
    conditional testing for whether the lock was supposed to be fair or
    not, and now that you dropped that, it's fast? If so, then that's an
    extra argument for the old conditional fair/unfair being complete
    garbage.

    Alternatively, maybe you just took the old timings, and the above
    numbers are for the old unfair code, and *not* for the actual patch
    you sent out?

    So please double-check and verify.

    Linus


    \
     
     \ /
      Last update: 2013-11-22 20:41    [W:8.477 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site