Messages in this thread | | | Date | Tue, 07 Jul 2015 17:59:59 -0400 | From | Waiman Long <> | Subject | Re: [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
| |