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

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.