> I'm one of those old fashioned people who thinks that a deadlock with
> an upper bound is much better than one without.
It is. But nevertheless, SCHED_IDLE is a good instrument
for well-behaving apps. I have ran a much more primitive
version of the patch for over half a year and have seen
only one (3-minute) hang.
Other workloads might give different results, but that's
why the sysctl switch is there...
Another possibility is adding priority inheritance code
to the _slow path_ of the locking code (ie. only try the
unlocking code if you can't get the lock within a second).
Rik -- Open Source: you deserve to be in control of your data.
+-------------------------------------------------------------------+
| Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
| Linux Memory Management site: http://www.linux.eu.org/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/