Messages in this thread | | | Date | Tue, 27 Jul 1999 08:31:45 -0600 | From | yodaiken@chelm ... | Subject | Re: low priority soft RT? |
| |
On Tue, Jul 27, 1999 at 04:25:21PM +0200, Rik van Riel wrote: > 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...
I'm one of those old fashioned people who thinks that a deadlock with an upper bound is much better than one without.
> Then throw in SCHED_RR or SCHED_FIFO processes and you're > gone.
But SCHED_RR is a problem on its own, is it not?
setsched(SCHED_RR) while(i < 100 ){ g = g+1; /* oops, I forgot to increment i*/ }
And inetd never runs again. > > 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/
| |