Re: Real-time pre-emption kswapd/kscand questions

From: Bob Hauck (postmaster_at_localhost.localdomain)
Date: 11/29/04 

Date: Sun, 28 Nov 2004 21:00:33 -0500

["Followup-To:" header set to comp.os.linux.development.system.]
On Sun, 28 Nov 2004 19:07:45 GMT, Joseph Gwinn <JoeGwinn@comcast.net> wrote:
> In article <h98m72-f7j.ln1@breadbin.mine.nu>,
> Jan Knutar <shadowjksp@yahoo.se> wrote:
>
>> Tom wrote:
>>
>> > Are there other real time Linux extensions/patches that might be good
>> > candidates for addressing this problem?

Note that there are some motherboards out there that just can't be used
for real-time (most laptops for instance). Before you do anything else
you should get the RTAI live CD:

<http://issaris.homelinux.org/~takis/projects/rtai/>

This will run some tests on your motherboard and tell you what the
expected latency and timing jitter are under RTAI. RTLinux ought to
give roughly similar results.

>> Ingo Molnar has been making realtime patches lately, which are
>> supposedly pretty close to achieving hard realtime capability.
>>
>> http://people.redhat.com/mingo/realtime-preempt/
>
> I've been following this too. They are still working out numerous
> stability issues, and a bunch of timing glitches, but the current test
> builds already achieve respectable soft realtime behavior, with only
> two in a million samples exceeding 50 microseconds on a 600 MHz
> processor.

One problem with this approach is that it is statistical. A million
cycles at one kilohertz is only a little over 15 minutes. For some
applications it is ok to glitch every 15 minutes or so, for others not.

Another problem is that interrupt disables and such are determined not
just by the real-time code path, but also by every other kernel module
or driver that's loaded at the same time. If you want to use such a
kernel in a hard real-time application you have to validate it with the
combination of modules that you are using. In addition, driver writers
aren't in general going to worry too much about interrupt disable times,
because few users care about that, so it becomes an ongoing problem to
re-validate every new version.

A sub-kernel approach like RTAI or RTLinux can guarantee timing
regardless of the drivers Linux uses. Well, almost, there are still
some things to consider (e.g. PCI bus hogging, SMI), but the universe of
possible problems is a lot smaller. You mostly only need to worry about
the specific drivers you will be using on the real-time side, not every
driver that's loaded.

There are disadvantages as well of course, because you essentially have
to partition your application, but if you have a hard real-time
requirement it is usually going to be easier to meet it with the RTLinux
approach than with a general-purpose kernel.

> I would be surprised if it took more than a year or perhaps two for
> the Linux community to find and fix the various causes, and it seems
> likely that Linux itself will soon become realtime enough for many
> traditional embedded realtime applications.

It is realtime enough for many applications now, but not so much for
others. If an application can tolerate an occasional missed deadline,
or don't have any strict timing requirements at all, then you can use
the preemptible kernel approach. Lots of embedded apps are like that,
more than you might think.

But there is another reason for reducing latency in the kernel even on
the desktop, and that is to support multimedia apps better. I think
Linux is just about there in that respect. 

-- 
 -| Bob Hauck
 -| To Whom You Are Speaking
 -| http://www.haucks.org/

Relevant Pages

  • Re: Real-time pre-emption kswapd/kscand questions
    ... for real-time. ... >> supposedly pretty close to achieving hard realtime capability. ... or driver that's loaded at the same time. ... kernel in a hard real-time application you have to validate it with the ...
    (comp.os.linux.development.system)
  • Re: Real-time pre-emption kswapd/kscand questions
    ... >> builds already achieve respectable soft realtime behavior, ... > or driver that's loaded at the same time. ... > kernel in a hard real-time application you have to validate it with the ... In a marketing battle between standard Linux and RTLinux, ...
    (comp.os.linux.development.system)
  • Re: profiler which does not just sum up used time
    ... I think drivers entirely in non-pageable memory and using interrupt handlers can be realtime, ... There are only threads executing user mode code, and threads executing kernel mode code (be it from a 3rd party driver, bundled driver, or core kernel). ... I know that there are only threads, or they run in user mode or kernel mode, what I'm trying to explain is that kernel code can run at real-time priority levels without the need to execute driver code, such code can even run at IRQL 1 or 2. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Device Driver that uploads its own code?
    ... driver, where the actual driver code logic is programmed in at runtime and ... but a common control loop might implement what's called PID ... approach near Real-Time performance for simple applications running on ... user mode and kernel mode. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Device Driver that uploads its own code?
    ... use any kernel mode DLL's with your driver. ... Don Burn (MVP, Windows DDK) ... Windows 2k/XP/2k3 Filesystem and Driver Consulting ... real-time and linear, the idea of fluctuating state and variable latency ...
    (microsoft.public.win32.programmer.kernel)