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 12:35 PM, Waiman Long <waiman.long@hp.com> wrote:
>
> Yes, the extra latency of the fair lock in earlier patch is due to the need
> to do a second cmpxchg(). That can be avoided by doing a read first, but
> that is not good for good cache. So I optimized it for the default unfair
> lock. By supporting only one version, there is no need to do a second
> cmpxchg anymore.

Ok, thanks.

> I reran the timing test on the 2.93GHz processor. The timing is the
> practically the same. I reused the old one for the 2.4GHz processor.

Sounds good. I just wanted to make sure the numbers were sane.

Linus


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