Messages in this thread | | | Subject | Re: [PATCH v8 07/19] locking/rwsem: Implement lock handoff to prevent lock starvation | From | Waiman Long <> | Date | Tue, 4 Jun 2019 12:00:33 -0400 |
| |
On 6/4/19 5:12 AM, Boqun Feng wrote: > On Tue, Jun 04, 2019 at 11:26:30AM +0800, Yuyang Du wrote: >> On Tue, 4 Jun 2019 at 11:03, Yuyang Du <duyuyang@gmail.com> wrote: >>> Hi Waiman, >>> >>> On Tue, 21 May 2019 at 05:01, Waiman Long <longman@redhat.com> wrote: >>>> Because of writer lock stealing, it is possible that a constant >>>> stream of incoming writers will cause a waiting writer or reader to >>>> wait indefinitely leading to lock starvation. >>>> >>>> This patch implements a lock handoff mechanism to disable lock stealing >>>> and force lock handoff to the first waiter or waiters (for readers) >>>> in the queue after at least a 4ms waiting period unless it is a RT >>>> writer task which doesn't need to wait. The waiting period is used to >>>> avoid discouraging lock stealing too much to affect performance. >>> I was working on a patchset to solve read-write lock deadlock >>> detection problem (https://lkml.org/lkml/2019/5/16/93). >>> >>> One of the mistakes in that work is that I considered the following >>> case as deadlock: >> Sorry everyone, but let me rephrase: >> >> One of the mistakes in that work is that I considered the following >> case as no deadlock: >> >>> T1 T2 >>> -- -- >>> >>> down_read1 down_write2 >>> >>> down_write2 down_read1 >>> > Not sure I understand the whole context here, but isn't adding a third > independent task makes this a deadlock? > > T1 T2 T3 > -- -- -- > > down_read1 down_write2 > down_write1 > down_write2 down_read1 > > from the perspective of lockdep, we cannot be sure whether there will > a T3 or not.
Yes, that will be a deadlock even with the my rwsem patch applied, as it will still try to preserve the reader-writer ordering. So it will certainly be safer to have the same lock ordering for both tasks.
> > In case that I mis-understood you, maybe your point is about in the > above case whether "down_read1" on T2 can *gauranteedly* steal (in the > sense of breaking the fairness) the read lock after Waiman modification? > If so, I will wait for Waiman's response ;-)
With my patchset applied, the reader-writer ordering is still supposed to be preserved. Of course, there can be exceptions depending on the exact timing, but we can't rely on that to prevent deadlock.
Cheers, Longman
| |