Re: PI patch against 2.6.16-rt9

[Ingo Molnar <mingo@elte.hu>]

* Esben Nielsen <simlo@phys.au.dk> wrote:

> The point is: It does not matter that is another chain!
> 
> It will _not_ boost any task which doesn't need boosting, because it 
> is not boosting according to current->prio but always 
> task->pi_waiters. So all it does is to fix the priorities on some 
> tasks. There is absolutely nothing wrong with that. [...]

doh, you are right, i missed that. All the state to do the boosting is 
contained in a single entry along the chain, so no prior information is 
needed.

the problem with deadlock detection remains though. Can we live with 
deadlock detection being a bit statistical? I think we can: deadlock 
detection is for _bugs_, no application should rely on it to provide 
actual functionality. (if it still does it will still work fine, but we 
dont design for them.) Also, if we walk long enough (say 1024 entries) 
the probability of a false positive ought to be pretty low. So i think 
the following type of deadlock detection ought to be pretty OK:

 - check whether we get back to 'current'.

 - check whether we exceed a configurable limit of steps

most 'sane' deadlocks will be detected quickly: they'll lead back to 
'current' and the kernel returns. On the off chance of the chain-walking 
getting lured into a completely unrelated chain the limit will catch it.

	Ingo