On Fri, Jun 30, 2000 at 11:54:23PM -0400, Paul Barton-Davis wrote:
> >> Imagine that Linux was a preemptable kernel (I'm *not* advocating it,
> >> just using it as an example), and we ensure that our audio thread has
> >> the highest SCHED_FIFO priority, and we ensure that interrupts are
> >> never disabled for more than a few usecs.
> >
> >That is, imagine that Linux guarantees that the highest priority
> >thread runs within some T usecs. Then Linux would be a RTOS.
>
> But it wouldn't have achieved it using *any* specifically RT
> techniques. The kernel just became preemptable, which is a necessary
> and insufficient condition for hard RT. Given that a context switch is
I don't know what a "specifically RT technique" is and I don't care
how its done -- if the kernel can promise to always respond to an interrupt
within some bound, then the kernel offers a hard realtime guarantee.
And, for what it's worth, my professional opinion is that this is incredibly
hard to do and never worth doing in a kernel that also wants to offer
high speed networking, files systems, and guis.
I'm sure Ingo will tell you that his patch is designed to make long
latencies _rare_ not impossible.
> >You cannot ask for a timing guarantee and not ask for a RTOS -- and
> >even most, so-called RTOS's don't provide this.
>
> Au contraire. I think I have outlined a scenario that *would* provide
> a timing guarantee, but would definitely not constitute an RTOS. Very
> few people who currently need RTLinux or use QNX et alia would find
> such a kernel adequate for their RT needs. Yet it would be adequate
> for ours.
This is an argument over wording, but it is important wording. If you
provide a timing guarantee, by standard engineering/computer science
terms, you are hard realtime. DOS can be used as a hard realtime kernel
and neither Linux nor NT can. It makes no difference that DOS is less
convenient to use than RTLinux or QNX (who actually only claim "typical"
interrupt latency last time I looked).
The wording is important because is makes clear what you want:
Goal A:
I want low latency Linux where typical interrupt response time is
under K ms and violations are rare -- usually no more than one
every T hours under such and such a load.
Goal B:
I want hard realtime guarantees in Linux, but I don't need a full
realtime operating system, just promise my application's hard
realtime requirement is met.
In my humble opinion: Goal A is great, Goal B is horrible.
> The only subset that has to be RT safe is scheduling. The rest is not
> part of the central issue here.
Paul: don't use the word "only" to describe hard realtime scheduling.
That's the absolute heart of hard realtime.
> but i continue to maintain that because the audio thread in these apps
> can be reduced a purely computational process, with no memory, i/o or
> other system resource issues, it can be solved (not that it *should*
> be solved this way, but it can be) by using a fully-preemptable kernel
> that does not satisfy most of the requirements of an RTOS.
And I continue to believe that a fully-preemptable general
purpose kernel is like a microkernel -- a delightful theoretical concept
that has been shown by repeated experiment to be a horrible
practical experience. Of course, technological changes and a smart
person or 10 may prove me to be wrong, but it's not the kind of
experiment that would be good to try with the main development tree
of a production kernel.
>
> --p
>
> -
> 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/
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.- 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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:09 EST