Messages in this thread | | | Subject | Re: PI patch against 2.6.16-rt9 | From | Thomas Gleixner <> | Date | Wed, 29 Mar 2006 01:59:23 +0200 |
| |
On Wed, 2006-03-29 at 00:34 +0100, Esben Nielsen wrote: > > Your method is tempting, but I do not see how it works out right now > > It works for PI.
Well, works and effective are two things. In the worst case it introduces scheduler floods.
> It might give false positives for deadlock detection even > without signals involved. But that might be solved by simply checking > again.
Which is even more broken. Rechecking is less deterministic as the global lock fall back solution.
> If it is stored on a task when they blocked on a lock it > could be seen if they had released and reobtained the task since the last > traversal.
-ENOPARSE
> If I should choose between a 100% certain deadlock detection and > rescheduling while doing PI I would choose that latter as that gives a > deterministic RT system. Are there at all applications depending on > deadlock detection or is it only for debug perposes anyway?
No, userspace can request deadlock checking and we have to return -EDEADLK in that case.
[EDEADLK] A deadlock condition was detected or the current thread already owns the mutex.
Returning false positives might break well designed applications and prevent real deadlock detection.
Btw, your get/put_task proposal adds two atomic ops. Atomic ops are implicit memory barriers and therefor you add two extra slow downs into the non conflict case.
tglx
- 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/
| |