How “Real-Time” is Linux 2.6?

Question

I am looking at moving my product from an RTOS to embedded Linux. I don't have many real-time requirements, and the few RT requirements I have are on the order of 10s of milliseconds.

Can someone point me to a reference that will tell me how Real-Time the current version of Linux is?

Are there any other gotchas from moving to a commercial RTOS to Linux?

Answer 1

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.

Answer 2

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

Answer 3

The answer is probably "good enough".

If you're running an embedded system, you probably have control of all or most of the software on the box.

Stock Linux 2.6 has several features suitable for low-latency tasks - chiefly these are:

• Scheduling policies
• Memory locking

Assuming you're using a single-core machine, if you have just one task which has set its scheduling policy to SCHED_FIFO or SCHED_RR (it doesn't matter which if you have just one task), AND locked all its memory in with mlockall(), then it WILL get scheduled as soon as it is ready to run.

Then the only thing you'd have to worry about was some non-preemptable part of the kernel taking longer than your acceptable latency to complete - which is unlikely to happen in an embedded system unless something bad happens, such as extreme memory pressure, or your drivers are dodgy.

I guess "try it and see" is a good answer, but that's probably rather complicated in your case (and might involve writing device drivers etc).

Look at the doc for sched_setscheduler for some good info.

Answer 4

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 in mind while writing realtime applications?

Taking care of the following during the 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 as fopen(). (Opening of files does the mmap() system call, which generates a page-fault).
• If you use 'compile time global variables' and/or 'compile time global arrays', then use mlockall() to prevent page faults when accessing them.

more information: HOWTO: Build an RT-application

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