Aka. priority inheritance, but then in a cheap, effective
and simplified form. I guess even Victor could be satisfied
with a situation like this...
> 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.
Promoting a SCHED_IDLE process to SCHED_OTHER when it
enters the kernel or holds a lock would be a good
solution. It involves removing the special run queue
for SCHED_OTHER processes (sorry Richard), a small
adjustment to goodness() and a check for SCHED_OTHER
in the priority recalculation code.
The goodness() piece will look approximately
like this:
if (p->policy == SCHED_OTHER) {
if (p->lock_depth >= 0)
return 1;
else
return -1;
}
But before doing the Wrong Thing(tm) and ending up
with a defective kernel I'll ask you guys first :)
cheers,
Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
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/