Re: Schedule idle

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 11 Nov 1998 15:59:14 +1100

Steve VanDevender writes:
> Rik van Riel writes:
> > In my view, RT tasks really should have absolute
> > priority over non-RT tasks and static priority
> > within it's own class.
>
> You know, what's sad about this continued debate about "RT" is
> that there is a persistent failure to understand that
> "real-time", as it is conventionally used, means "guaranteed
> response time". It does not mean "ASAP scheduling" or "minimum
> scheduling latency". There are inherent conflicts between
> real-time and timesharing that are not easy, or maybe not even
> possible, to resolve.
>
> If Richard Gooch had taken the tack that the Linux scheduler had
> undesirable latency when proposing his scheduler patches, I don't
> think I or several other people would have objected. But when he
> claimed that his patches would make Linux a better "real-time"
> operating system, I did object, because you can't make a
> real-time operating system out of a timesharing system just by
> fiddling with the scheduler, or implementing "priority
> inheritance", or doing other things that have been proposed.

Richard Gooch, speaking here for himself, never said that his patches
would make the Linux scheduler hard-RT. He in fact pointed out other
parts of the kernel (i.e. network drivers disabling interrupts for 1.5
ms) as being the greatest hurdles to hard-RT in the kernel.

> Linux is a timesharing system, by design, and that assumption is
> pervasive though things like interrupt handling and the driver
> model. Anyone who thinks that Linux can be made into a real-time
> system by fiddling with the scheduler and maybe a couple of other
> things is deluding himself.

I'm aiming for soft-RT not hard-RT. I'm aiming for soft-RT with lower
latencies. In many cases, soft-RT is "good enough", and lowering
latencies moves the boundary of when the kernel is "good enough".

BTW: to those who would deride SCHED_IDLE and fixing potential
deadlocks by implementing priority inheritance, I'll point out that
the underlying bug (sleeping while holding a lock on a resource) will
cause problems even if SCHED_OTHER was the *only* scheduling class in
the whole system.

Yeah, that's right, even if we rip out the RT scheduling classes and
not include SCHED_IDLE, the sleep-with-lock bug still presents a
problem. A heavily niced process (nice 19) which messes with the FS
can significantly degrade the performance of the FS for other
processes. Imagine the following scenario:

- nice 19 process bangs on FS
- nice 4 process eats CPU
- normal users try to use FS.

Here we don't get deadlock, but we do get lockouts while the nice 19
process goes to sleep holding a resource lock. Eventually the user
processes will get access to the FS again, but only after a long wait.

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/