Re: RT patch acceptance

[Philippe Gerum]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/