lkml.org 
[lkml]   [1999]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.228 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site