Re: [RT] bad BUG_ON in rtmutex.c

[Daniel Walker <dwalker@mvista.com>]

On Tue, 2006-04-18 at 09:50 -0400, Steven Rostedt wrote:
> On Tue, 2006-04-18 at 06:11 -0700, Daniel Walker wrote:
> 

> 
> > 
> > I was looking over the code, and it seems like once all the chain
> > adjusting bottoms out you would end up with the correct priorities in
> > the waiter structures .. Cause whatever task made the priority
> > adjustment would just end up resetting the pi_waiters during it's
> > adjustment process. (Seems like there's room for optimization
> > though ..) 
> 
> I guess I just reiterated above what you are saying here.  Not sure if
> this can be optimized.  You're talking about optimizing a case that
> would seldom happen, but in doing so you stand a great chance of slowing
> down the normal case.

I'm not really working on it, but on a bigger SMP machine it might not
be that uncommon .. PI is running on all tasks now isn't it? It seems
like a simple check could be at the same point as the BUG_ON() we're
talking about .. <speculation> If that BUG_ON() triggers , it means the
task is walking the lock chain at the same time as another task on the
same chain, so you could make the lower prio chain stop at that point ..
no?

> To keep latencies down, we are letting the PI chain walk be preempted,
> by releasing locks.  It's understood that the chain can then change
> while walking (big debate about this between Ingo, tglx and Esben).  But
> at the end, we decided on it being better to have latencies down, and
> just make adjustments when they arise.  This also keeps the latencies
> bounded, since the old way was harder to know the worst case (PI chain
> creep).

I can imagine. Seems like PI is always a point of controversy .

> BUT!  I need to take another good look at the code, and maybe my
> previous example of the failed BUG_ON is really a clue that there exists
> a deeper bug.  If the processes D and E from my last example were of
> different priorities, but still higher than A, could the end result be
> setting A to the lower of the two?  This would be a bug, because then A
> would not inherit the correct priority!

Did that BUG_ON ever trigger for you? I don't know how you would end up
in that state without at least two chain walkers on different cpu's ..

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/