Re: [PATCH v2] locking/rwsem: Take read lock immediate if queue empty with no writer

[Davidlohr Bueso <dave@stgolabs.net>]

On Wed, 18 Jul 2018, Waiman Long wrote:

>The key here is that we don't want other incoming readers to observe
>that there are waiters in the wait queue and hence have to go into the
>slowpath until the single waiter in the queue is sure that it probably
>will need to go to sleep if there is writer.
>
>With a constant stream of incoming readers, a major portion of them will
>observe the a negative count and be serialized to enter the slowpath.
>There are certainly other readers that do not observe the negative count
>in the in between period after one reader clear the count in the unlock
>path and a waiter set the count to negative again. Those readers can go
>ahead and do the read in parallel. But it is the serialized readers that
>cause the performance loss and the observation of spinlock contention in
>the perf output.

This makes sense and seems feasible in that the optimization is done with
the wait_lock held.

>
>It is the constant stream of incoming readers that sustain the spinlock
>queue and the repeated clearing and negative setting of the count.

This would not affect optimistic spinners that haven't yet arrived at the
waitqueue phase because the lock is anonymously owned, so they won't spin
in the first place, right?

Thanks,
Davidlohr