Re: RT Mutex patch and tester [PREEMPT_RT]

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 2006-01-23 at 10:33 +0100, Esben Nielsen wrote:
> On Sun, 22 Jan 2006, Bill Huey wrote:
> 
> > On Mon, Jan 23, 2006 at 01:20:12AM +0100, Esben Nielsen wrote:
> > > Here is the problem:
> > >
> > > Task B (non-RT) takes BKL. It then takes mutex 1. Then B
> > > tries to lock mutex 2, which is owned by task C. B goes blocks and releases the
> > > BKL. Our RT task A comes along and tries to get 1. It boosts task B
> > > which boosts task C which releases mutex 2. Now B can continue? No, it has
> > > to reaquire BKL! The netto effect is that our RT task A waits for BKL to
> > > be released without ever calling into a module using BKL. But just because
> > > somebody in some non-RT code called into a module otherwise considered
> > > safe for RT usage with BKL held, A must wait on BKL!
> >
> > True, that's major suckage, but I can't name a single place in the kernel that
> > does that.
> 
> Sounds good. But someone might put it in...

Hmm, I wouldn't be surprised if this is done somewhere in the VFS layer.

> 
> > Remember, BKL is now preemptible so the place that it might sleep
> > similar
> > to the above would be in spinlock_t definitions.
> I can't see that from how it works. It is explicitly made such that you
> are allowed to use semaphores with BKL held - and such that the BKL is
> released if you do.

Correct.  I hope you didn't remove my comment in the rt.c about BKL
being a PITA :) (Ingo was nice enough to change my original patch to use
the acronym.) 

> 
> > But BKL is held across schedules()s
> > so that the BKL semantics are preserved.
> Only for spinlock_t now rt_mutex operation, not for semaphore/mutex
> operations.
> > Contending under a priority inheritance
> > operation isn't too much of a problem anyways since the use of it already
> > makes that
> > path indeterminant.
> The problem is that you might hit BKL because of what some other low
> priority  task does, thus making your RT code indeterministic.

I disagree here.  The fact that you grab a semaphore that may also be
grabbed by a path while holding the BKL means that grabbing that
semaphore may be blocked on the BKL too.  So the length of grabbing a
semaphore that can be grabbed while also holding the BKL is the length
of the critical section of the semaphore + the length of the longest BKL
hold.

Just don't let your RT tasks grab semaphores that can be grabbed while
also holding the BKL :)

But the main point is that it is still deterministic.  Just that it may
be longer than one thinks.

> 
> > Even under contention, a higher priority task above A can still
> > run since the kernel is preemptive now even when manipulating BKL.
> 
> No, A waits for BKL because it waits for B which waits for the BKL.

Right.

-- Steve

PS. I might actually get around to testing your patch today :)  That is,
if -rt12 passes all my tests.