On Mon, Mar 13, 2017 at 03:25:52PM +0100, Thomas Gleixner wrote: > On Mon, 13 Mar 2017, Peter Zijlstra wrote: > > > On Tue, Mar 07, 2017 at 03:31:50PM +0100, Thomas Gleixner wrote: > > > On Sat, 4 Mar 2017, Peter Zijlstra wrote: > > > > > > > The problem with returning -EAGAIN when the waiter state mismatches is > > > > that it becomes very hard to proof a bounded execution time on the > > > > operation. And seeing that this is a RT operation, this is somewhat > > > > important. > > > > > > > > While in practise it will be very unlikely to ever really take more > > > > than one or two rounds, proving so becomes rather hard. > > > > > > Oh no. Assume the following: > > > > > > T1 and T2 are both pinned to CPU0. prio(T2) > prio(T1) > > > > > > CPU0 > > > > > > T1 > > > lock_pi() > > > queue_me() <- Waiter is visible > > > > > > preemption > > > > > > T2 > > > unlock_pi() > > > loops with -EAGAIN forever > > > > So this is true before the last patch; but if we look at the locking > > changes brought by that (pasting its changelog here): > > I was referring to the state before the last patch and your wording in the > changelog of this being very unlikely.
Yeah, I understand that. Lemme see what I can do to clarify both situations.
