Re: RT patch acceptance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bill Huey (hui) wrote:
On Tue, May 24, 2005 at 06:31:41PM -0400, Karim Yaghmour wrote:

<repeating-myself>
From my POV, it just seems that it's worth asking a basic
question: what is the least intrusive modification to the Linux
kernel that will allow obtaining hard-rt and what mechanisms
can we or can we not build on that modification? Again, my
answer to this question doesn't matter, it's the development
crowd's collective answer that matters. And in championing
the hypervisor/nanokernel path, I could turn out to be horribly
wrong. At this stage, though, I'm yet unconvinced of the
necessity of anything but the most basic kernel changes (as
in using function pointers for the interrupt control path,
which could be a CONFIG_ also).


I know what you're saying and it's kind unaddressed by various
in this discussion.

When I think of the advantages of a single over dual image kernel
system I think of it in terms of how I'm going to implement QoS.
If I need to get access to a special TCP/IP socket in real time
with strong determinancy you run into the problem of crossing to
kernel concurrency domains, one preemptible one not, with a dual
kernel system and have to use queues or other things to
communicate with it. Even with lockless structures, you're still
expressing latency in the Linux kernel personality if you have
some kind of preexisting app that's already running in an atomic
critical section holding non-preemptive spinlocks.

However this is not RTAI as I understand it since it can run N
number of image for each RT task (correct?)


Basically, yes. The RTAI/fusion machinery makes sure that either Linux or the RTAI co-scheduler are alternately in control of the RT tasks they share, depending on the code they happen to tread on, and use the same priority scheme so that you don't end up losing your effective RTAI priority just because you happen to issue a regular system call that migrates you under the control of the Linux kernel to process it.

It turns out that your worst-case sched latency when using Linux services in RT context is mainly defined by the granularity of the Linux kernel, since the co-scheduler has very simple synchronization constraints, and can be activated at any time by interrupts regardless of the current masking state set by the Linux kernel. For the same reason, if the task keeps using only RTAI-specific services, then your worst-case is always close to the hardware limit.

Having multipule images helps out, but fails in scenarios where
you have to have tight data coupling. I have to think about things
like dcache_lock, route tables, access to various IO system like
SCSI and TCP/IP, etc...

A single system image makes access to this direct unlike dual kernel
system where you need some kind of communication coupling. Resource
access is direct. Modifying large grained subsystems in the kernel
is also direct. As preexisting multimedia apps use more RT facilities,
apps are going to need something more of a general purpose OS to make
development easiler. These aren't traditional RT apps at all, but
still require hard RT response times. Keep in mind media apps use
the screen, X11, audio device(s), IDE/SCSI for streaming, networking,
etc... It's a comprehensive use of many of the facilities of kernel
unlike traditional RT apps.

Agreed, not all apps requiring bounded latencies are sampling i/o ports on the bare metal at 20Khz, just because there are different levels of RT requirements. For this reason, RTAI's fusion track has always been meant to leverage and complement the undergoing efforts to improve the vanilla kernel wrt overall latency and proper priority enforcement, in the current case PREEMPT_RT and its PI implementation. RTAI (all tracks included) addresses a small niche of applications which really can't take any chance with unexpected latencies when time constraints are extreme, underlying hardware has limited capacities, and/or detection of 3rd party code randomly inducing jittery in a large kernel codebase is out of reach. A niche which is being shared with other RTOS and as you already pointed out, may even get smaller once Linux latencies eventually becomes predictable and bounded within a reasonably low micro-sec range, as some people who don't actually need extremely low worst-case latencies close to the hardware limits eventually figure out that vanilla Linux on full preemption steroids is up to the job.

As said earlier, one of the main goals of the fusion track within the RTAI project is about providing a convenient way for the remaining niche users to access both worlds seamlessly, so that the covered spectrum of applications with varying RT requirements could be broader. In that sense, you can bet that we are among the supporters of the PREEMPT_RT effort, because it magically solves half of the long-term issues involved with having a practical and sound integration between fusion and Linux.


Now, this doesn't necessarily replace RTAI, but a preemptive Linux
kernel can live as a first-class citizen to RTAI. I've been thinking
about merging some of the RTAI scheduler stuff into the RT patch.

I did it recently, crafting a combo patch between Adeos (needed by fusion) and PREEMPT_RT (0.7.44-03). The results running fusion over this combo are encouraging, even if things remain to be ironed.

uber-preemption Linux doesn't have a sophisticate userspace yet
and here RTAI clearly wins, no decent RT signal handling, etc...
There are other problems with it and the current implementation.
This is going to take time to sort out so RTAI still wins at this
point.


IMHO, RTAI will eventually achieve one of its major goals when it succeeds to smartly and transparently integrate with Linux, while still keeping the standard semantics for the RT tasks it manages. At this point, using RTAI or not will not be a matter of religion between mere Linux or co-kernel zealots, but a decision based on the required level of predictability that one may obtain in a particular hw/sw context. Hopefully.

I hope I addressed this properly, but that's the point of view
I'm coming from.

bill


--

Philippe.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux