Re: RT patch acceptance
From: James Bruce
Date: Mon May 30 2005 - 18:36:06 EST
Nick Piggin wrote:
Sorry James, we were talking about hard realtime. Read the thread.
hard realtime = mathematically provable maximum latency
Yes, you'll want a nanokernel for that, you're right. That's because
one has to analyze every line of code, and protect against introduced
regressions, which is almost impossible given the pace that Linux-proper
is developed. Then there's the other 95% of applications, for which a
"statistical RT" approach such as used in the RT patch suffice. So
arguing for a nanokernel for (provable) hard realtime is orthogonal to
the discussion of this patch, and we apparently don't actually disagree.
If you look at your first two messages in this thread however, you seem
to be offering a nanokernel approach (in particular RTAI as suggested by
Cristoph) as an alternative to the RT-patch. This is sort of confused
by the fact that Ingo called it "hard realtime" because he measured a
maximum latency during a stress test. Unfortunately that's not really
hard realtime if you are just measuring it; Rather its "really damn good
soft realtime". An analysis of code paths could be done to determine if
something really does satisfy hard-RT constraints, but to my knowledge
that's not on the table at this point. So you're discussing soft
realtime if you're dicussing the RT patch.
So its really just a misunderstanding; Nanokernels certainly still have
a place for some applications even with the RT patches applied (Ingo has
said as much). However expecting audio applications such as Jack to
have to use RTAI is kind of silly, and would end up annoying the authors
of both (I'm sure the RTAI people have better things to do than support
ALSA drivers in RT mode).
What's more, I don't think you understand how a nanokernel solution
would work, nor have much idea about the complexity of implementing
it in Linux (although that could have been a result of your thinking
that we weren't talking about hard-rt).
Nanokernels for RT aren't that difficult when compared with the RT
patch, I agree with you on that. An RT scheduler is also pretty damn
easy to write (certainly easier than a general purpose one that can't
arbitrarily starve low-prio tasks). The complexity comes in when you
have to fork drivers to make them RT-compatible, or upcall into existing
ones in which case you're making the same modifications to code as in
the RT patch. Nanokernels work great for simpler hard realtime apps,
but poorly for complex softer-realtime apps. The RT patch addresses the
latter quite well.
And my questions for which I got no answer were things like
"why is a single kernel superior to a nanokernel for hard-RT?",
It's not better; The two methods best serve different types of applications.
"what deterministic services would a hard-RT Linux need to provide?"
To start out with, nothing; It's better to let such applications develop
iteratively. In developing things such as Jack or my robot code, we
find out what things we can call without screwing up latency, and if we
think something could be fixed, we might ask about it on LKML to see if
someone will fix it. This model works pretty well in open source. You
can see my question about the Linux serial driver a few years ago, or
the many threads about Jack on this list.
I realize you don't like this approach, but that's pretty much how
things have been working for a while. The Jack people are using the RT
patch now, and will come back when they find something that doesn't work
as well as it seems it should. They did the same with preempt and the
lowlatency patches before it. A fixed set of requirements would be
nice, but these applications are evolving just as the kernel does.
Err, your example was "reading a configuration file". Not exactly
rocket science my good man.
For the third time: One model is easier to program for than the other,
neither makes anything impossible. Writing applications in assembler
isn't rocket science either, but even for "hello world" I'd rather use a
compiled language.
Please explain how a split-kernel method supports a continuous
progression from soft-realtime to hard-realtime, where each set of API
calls has associated latency effects that may or may not be tolerable
for a given application. That's the problem space, and I can guarantee
applications exist all along that progression, and many don't fall
cleanly into one side or the other.
You say this like you have a confabulous solution ready to plonk
into the Linux kernel.
I certainly don't, but I think someone else is on to a solution that can
achieve this eventually. When someone questioned "who really
wants/needs this stuff", then I piped up, along with a few others.
Many of us "RT-people" would love to to see the ordinary kernel get as
far as it can without a radical change in programming model. That means
we could write one Posix app that is realtime on Linux, and working but
possibly not realtime on older Linux versions and other operating
systems. We could tell users "use Linux 2.6.14 if you don't want the
system to hiccup". That is preferable to writing a special version of
the software for Linux just to get soft RT. That said, there will
always be a place for other approaches such as nanokernels for someone
controlling the proverbial industrial saw. For those applications you
want proof of hard realtime performance, but at the same time they don't
require streaming data off a disk or onto the network, nor using audio
hardware or serial radios for output.
[snip part about bothering to understand RT approaches]
I really hope we understand each other now, but if not I guess it wasn't
to be. Hopefully someone got something out of reading this discussion,
but I won't be posting on this branch of the thread anymore either.
- Jim Bruce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/