So surely the fix is to have the SCHED_IDLE process temporarily lose its
SCHED_IDLE status when it obtains any form of lock.
You could do this by keeping a counter of the number of locks held, and a field
for the 'intended' scheduling policy. When you increase said counter, set the
actual scheduling policy to SCHED_OTHER. When you decrease the counter to zero,
copy the 'intended' policy to the actual policy.
This _is_ basically the 'classic' fix mentioned - the process holding the
lock(s) attains the higher priority for the duration.
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
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/