lkml.org 
[lkml]   [2015]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] locking/qrwlock: Use direct MCS lock/unlock in slowpath
On 07/07/2015 07:24 AM, Peter Zijlstra wrote:
> On Mon, Jul 06, 2015 at 11:43:06AM -0400, Waiman Long wrote:
>> Lock waiting in the qrwlock uses the spinlock (qspinlock for x86)
>> as the waiting queue. This is slower than using MCS lock directly
>> because of the extra level of indirection causing more atomics to
>> be used as well as 2 waiting threads spinning on the lock cacheline
>> instead of only one.
> This needs a better explanation. Didn't we find with the qspinlock thing
> that the pending spinner improved performance on light loads?
>
> Taking it out seems counter intuitive, we could very much like these two
> the be the same.

Yes, for lightly loaded case, using raw_spin_lock should have an
advantage. It is a different matter when the lock is highly contended.
In this case, having the indirection in qspinlock will make it slower. I
struggle myself as to whether to duplicate the locking code in qrwlock.
So I send this patch out to test the water. I won't insist if you think
this is not a good idea, but I do want to get the previous 2 patches in
which should not be controversial.

Cheers,
Longman


\
 
 \ /
  Last update: 2015-07-08 00:21    [W:0.150 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site