Messages in this thread | | | Date | Fri, 17 Jun 2022 10:43:16 -0400 | Subject | Re: [PATCH] locking/rwlocks: do not starve writers | From | Waiman Long <> |
| |
On 6/17/22 08:07, Peter Zijlstra wrote: > On Fri, Jun 17, 2022 at 02:10:39AM -0700, Eric Dumazet wrote: >> --- a/kernel/locking/qrwlock.c >> +++ b/kernel/locking/qrwlock.c >> @@ -23,16 +23,6 @@ void queued_read_lock_slowpath(struct qrwlock *lock) >> /* >> * Readers come here when they cannot get the lock without waiting >> */ >> - if (unlikely(in_interrupt())) { >> - /* >> - * Readers in interrupt context will get the lock immediately >> - * if the writer is just waiting (not holding the lock yet), >> - * so spin with ACQUIRE semantics until the lock is available >> - * without waiting in the queue. >> - */ >> - atomic_cond_read_acquire(&lock->cnts, !(VAL & _QW_LOCKED)); >> - return; >> - } >> atomic_sub(_QR_BIAS, &lock->cnts); >> >> trace_contention_begin(lock, LCB_F_SPIN | LCB_F_READ); > This is known to break tasklist_lock. > We certainly can't break the current usage of tasklist_lock.
I am aware of this problem with networking code and is thinking about either relaxing the check to exclude softirq or provide a read_lock_unfair() variant for networking use. I think tasklist_lock isn't taken from softirq context, but I may be wrong. Providing a read_lock_unfair() will require quite a bit of work in the supporting infrastructure as well.
Cheers, Longman
| |