Re: low priority soft RT?

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 28 Jul 1999 07:09:32 +1000

yodaiken@chelm.cs.nmt.edu writes:
> 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.

I think what Rik means is that a RT process can try to get a lock
(i.e. directory semaphore) which is held by a SCHED_OTHER process. The
SCHED_OTHER process stops getting CPU time, and thus cannot release
the lock. Hence we have deadlock. Of course, a RT process hitting the
FS is somewhat questionable, but in some cases is legitimate (i.e. you
have two RT processes, the high priority one queues data to the low
priority one which hits the FS), provided you know what you are doing.

SCHED_IDLE presents the same problem: SCHED_IDLE process holds a lock,
which locks out a SCHED_OTHER process. Again, permanently.

So SCHED_IDLE shouldn't be lambasted for making a deadlock possible,
because SCHED_OTHER (in the presence of RT processes) can do the
same. Which is why I support moving !SCHED_OTHER processes to
SCHED_OTHER when they call schedule(), and moving them back when
schedule() returns.

Regards,

Richard....

-
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/