Messages in this thread | | | Subject | Re: [PATCH v2] locking/rwsem: Take read lock immediate if queue empty with no writer | From | Waiman Long <> | Date | Mon, 23 Jul 2018 09:40:58 -0400 |
| |
On 07/23/2018 12:04 AM, Davidlohr Bueso wrote: > 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?
The reader fastpath would have incremented the active count before entering the slowpath. The spinning writer, seeing a non-zero active count, will not attempt to steal the lock until the reader decrement the count and set the waiting bias in one atomic op. Nothing will happen before that.
-Longman
| |