Re: PI patch against 2.6.16-rt9

Ingo Molnar
2006-03-29T12:37:59Z

* 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