Messages in this thread | | | Date | Wed, 29 Mar 2006 14:35:26 +0200 | From | Ingo Molnar <> | Subject | Re: PI patch against 2.6.16-rt9 |
| |
* 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 - 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/
| |