On Mon, 9 Nov 1998 20:33:28 +0100 (CET), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:
> On Sun, 8 Nov 1998 yodaiken@chelm.cs.nmt.edu wrote:
>> You must mean: "implement priority inheritance" -- "priority
>> inversion" is the error, "priority inheritance" is so-called "fix".
>> Priority based RT assumes that the highest priority runnable
>> process will advance at any time.
>> If the OS tries to believe both propositions at the same time it will die.
> Not neccesarily. There are certain things you can do do avoid this
> situation. Firstly, RT processes usually don't take up loads of CPU
> time. If they do, you're better off with a separate system anyway;
> you're right on that.
But SCHED_OTHER processes _do_ take up loads of CPU time.
> OTOH, I have been running RT processes for a long time now (can you
> say 1.3) without actually experiencing any of the problems you
> mentioned.
That's because, as you already pointed out, soft RT processes do not
typically lock themselves in a tight loop. They avoid that because it
is *defined* that such behaviour will lock up your system.
> The SCHED_IDLE idea is just an extension of the realtime paradigm. I
> take it you're not really serious about wanting to back _that_ out of
> the kernel.
SCHED_IDLE extends a realtime paradigm to time-sharing processes, and
that is broken. Strict priority levels let one process lock out lower
priority processes for good, without possibility of recovery. That's
fine if you are talking about carefully written realtime apps where you
need root privilege to set the priority level and where you are quite
explicitly accepting the need for careful coding. It is not OK if you
allow SCHED_OTHER processes to completely and permanently preempt a
SCHED_IDLE process which legally holds a semaphore. SCHED_OTHER should
not be able to lock things up.
By the way, I'm quite surprised that nobody has yet pointed out a
perfectly simple fix for the SCHED_IDLE issue, which is to disable the
SCHED_IDLE effect and revert to timeshared scheduling whenever a process
is blocked in kernel mode.
--Stephen
-
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/