Sunday, November 29, 2009

CONFIG_PREEMPT_RT kernel patch

On rt-users kernel mailing lists Linus said:
"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT" -- Linus Torvalds

As you may know that the standard build Linux kernel is always preempt high priority user-mode process when kernel-mode process is executing, this bad for time critical application. Realtime application need precise timing for it's work. Let say you control a motor machine, it's use many sensors to determine it's rotor position, you need to know each sensor's state by reading the sensor device. With a high speed motor, you will need to read sensor state for example every 1 milisecond and do something as soon as sensor state change. Imagine what will happen when the kernel-mode process is running and delaying your realtime application while you ask the machine to stop? of course disaster.

In 2.6 kernel version, there are some preemption setting introduced such as CONFIG_PREEMPT_VOLUNTARY and CONFIG_PREEMPT, but these are not meet a realtime application that need very small latencies. The PREEMPT_RT patch convert Linux to be fully preemptible kernel, this done with:
  • Making in-kernel locking-primitives (using spinlocks) preemptible though reimplementation with rtmutexes.

  • Critical sections protected by i.e. spinlock_t and rwlock_t are now preemptible. The creation of non-preemptible sections (in kernel) is still possible with raw_spinlock_t (same APIs like spinlock_t).

  • Implementing priority inheritance for in-kernel spinlocks and semaphores. For more information on priority inversion and priority inheritance please consult Introduction to Priority Inversion.

  • Converting interrupt handlers into preemptible kernel threads: The RT-Preempt patch treats soft interrupt handlers in kernel thread context, which is represented by a task_struct like a common user space process. However it is also possible to register an IRQ in kernel context.

  • Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to user space POSIX timers with high resolution.

Main Maintainer: Ingo Molnar, Thomas Gleixner