Messages in this thread | | | Subject | Re: [PATCH-tip v2 06/12] locking/rwsem: Wake up almost all readers in wait queue | From | Waiman Long <> | Date | Wed, 10 Apr 2019 13:08:28 -0400 |
| |
On 04/10/2019 12:50 PM, Davidlohr Bueso wrote: > On Fri, 05 Apr 2019, Waiman Long wrote: > >> When the front of the wait queue is a reader, other readers >> immediately following the first reader will also be woken up at the >> same time. However, if there is a writer in between. Those readers >> behind the writer will not be woken up. >> >> Because of optimistic spinning, the lock acquisition order is not FIFO >> anyway. The lock handoff mechanism will ensure that lock starvation >> will not happen. >> >> Assuming that the lock hold times of the other readers still in the >> queue will be about the same as the readers that are being woken up, >> there is really not much additional cost other than the additional >> latency due to the wakeup of additional tasks by the waker. Therefore >> all the readers up to a maximum of 256 in the queue are woken up when >> the first waiter is a reader to improve reader throughput. > > Before we stopped waking readers when a writer was encountered but > would otherwise wakeup _all_ readers. I don't understand why you want > to limit this to MAX_READERS_WAKEUP, otherwise I agree it's nice to > skip the writer and continue waking readers in the queue (with the > handoff > guarantees obviously). > > Would it not be better to do the MAX_READERS_WAKEUP limit only when > a writer is found? > > Thanks, > Davidlohr
There are 2 major reasons why there is a limit.
1) It will be unfair to the task that needs to spend so much of its own CPU time to wake up too many readers. 2) I want to avoid the extreme case that there are more than 32k readers in the wait queue and make the count overflow.
Cheers, Longman
| |