How "Real-Time" is Linux 2.6?

You can get most of your answers from the Real Time Linux wiki and FAQ

What are real-time capabilities of the stock 2.6 linux kernel?

Traditionally, the Linux kernel will only allow one process to preempt another only under certain circumstances:

• When the CPU is running user-mode code
• When kernel code returns from a system call or an interrupt back to user space
• When kernel code code blocks on a mutex, or explicitly yields control to another process

If kernel code is executing when some event takes place that requires a high priority thread to start executing, the high priority thread can not preempt the running kernel code, until the kernel code explicitly yields control. In the worst case, the latency could potentially be hundreds milliseconds or more.

The Linux 2.6 configuration option CONFIG_PREEMPT_VOLUNTARY introduces checks to the most common causes of long latencies, so that the kernel can voluntarily yield control to a higher priority task waiting to execute. This can be helpful, but while it reduces the occurences of long latencies (hundreds of milliseconds to potentially seconds or more), it does not eliminate them. However unlike CONFIG_PREEMPT (discussed below), CONFIG_PREEMPT_VOLUNTARY has a much lower impact on the overall throughput of the system. (As always, there is a classical tradeoff between throughput --- the overall efficiency of the system --- and latency. With the faster CPU's of modern-day systems, it often makes sense to trade off throughput for lower latencies, but server class systems that do not need minimum latency guarantees may very well chose to use either CONFIG_PREEMPT_VOLUNTARY, or to stick with the traditional non-preemptible kernel design.)

The 2.6 Linux kernel has an additional configuration option, CONFIG_PREEMPT, which causes all kernel code outside of spinlock-protected regions and interrupt handlers to be eligible for non-voluntary preemption by higher priority kernel threads. With this option, worst case latency drops to (around) single digit milliseconds, although some device drivers can have interrupt handlers that will introduce latency much worse than that. If a real-time Linux application requires latencies smaller than single-digit milliseconds, use of the CONFIG_PREEMPT_RT patch is highly recommended.

They also have a list of "Gotcha's" as you called them in the FAQ.

What are important things to keep inmind while writing realtimeapplications?

Taking care of the following duringthe initial startup phase:

• Call mlockall() as soon as possible from main().
• Create all threads at startup time of the application, and touch each page of the entire stack of each thread. Never start threads dynamically during RT show time, this will ruin RT behavior.
• Never use system calls that are known to generate page faults, such asfopen(). (Opening of files does themmap() system call, which generates apage-fault).
• If you use 'compile time global variables' and/or 'compile time globalarrays', then use mlockall() toprevent page faults when accessingthem.

more information: HOWTO: Build anRT-application

They also have a large publications page you might want to checkout.

Have you had a look at Xenomai? It will let you run "hard real time" processes above Linux, while still allowing you to access the regular Linux APIs for all the non-real-time needs.

There are two fundamentally different approaches to achieve real-time capabilities with Linux.

1) Patch the existing kernel with things like the rt-preempt patches. This will eventually lead to a fully preemptive kernel

2) Dual kernel approach (like xenomai, RTLinux, RTAI,...)

There are lots of gotchas moving from a RTOS to Linux.

Maybe you don't really need real-time?

I'm talking about real-time Linux in my training: http://www.reliableembeddedsystems.com/embedded-systems_7.html