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/