Messages in this thread | | | Date | Tue, 27 Jul 1999 16:25:21 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: low priority soft RT? |
| |
On Tue, 27 Jul 1999 yodaiken@chelm.cs.nmt.edu wrote: > On Tue, Jul 27, 1999 at 04:04:12PM +0200, Rik van Riel wrote: > > On Tue, 27 Jul 1999 yodaiken@chelm.cs.nmt.edu wrote: > > > Someone, maybe it was Linus, pointed out that the current range of > > > "nice" levels is totally arbitrary and simply increasing the range > > > would do good. > > > > Unfortunately, we showed him he was wrong and the deadlock > > could still happen with normal timeslicing processes and > > RT tasks... > > Can you tell me too?
Sure. If you have a bunch of normal, interactive and niced processes, then a high-priority process can wait for over a second before a lock (held by a niced process) is released and the high-priority process can continue.
Now, if we would follow Linus' idea and extend the range of niced processes, that time span could increase to 10 or even more seconds, effectively producing the same kind of 'deadlock' that SCHED_IDLE can produce -- only with an upper bound to it...
Then throw in SCHED_RR or SCHED_FIFO processes and you're gone.
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/
| |