Messages in this thread | | | Date | Fri, 22 Nov 2013 13:14:03 -0800 | Subject | Re: [PATCH v7 1/4] qrwlock: A queue read/write lock implementation | From | Linus Torvalds <> |
| |
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
| |