The Linux kernel has always been somewhat preemptive, but with the 2.6 kernel there were big improvements aimed at making the kernel almost fully preemptive and added the 'preemptive' compiling option, which has lead improvements to user response which is important for a desktop operating system. However these improvements have been less then stellar at reducing system latencies to a low level. Currently the stable versions of Linux 2.6 cannot be relied on to handle scheduling latencies under 100msec. For non-critical apps you can probably get scheduling down under 10-30msec, depending on the actual kernel version. This is better then 2.4 series, but not close to 2.4 series combined with low-latency patches.
Realtime-preempt is a set of patches for the latest version of the Linux kernel (2.6.12-rc6 at this writing). They are being developed by Ingo Molnar (a kernel hacker from Redhat) that brings the pre-emption capabilities to the next level. It's goal is to make the full fledged Linux kernel have as close to real-time response as possible. (As a warning, though, the realtime preempt patches are under going heavy development and have been for some times. It's not unusual for Ingo to update the realtime-preempt patch several times a day, or even within hours of each other. )
The original announcement of this is available here:
(link dead, sorry)
At that time it was called voluntary-preempt, but the goal of the patch has increased significantly since then.
The latest patch is available here:
By applying this patch it adds several configurable options to the kernel compile-time config system.
No Forced Preemption (Server)
Voluntary Kernel Preemption (Desktop)
Preemptible Kernel (Low-Latency Desktop)
Complete Preemption (Real-Time)
Old-Style Big Kernel Lock
As well as more debugging capabilities to aid in tracking down causes of additional kernel latencies. All the technical details of what all of this does and what all of it is for is a bit over my head.
Some information on various things:
Links to Linux RCU information:
What is RCU, Fundamentally?
A wiki on the subject:
To allow regular users, mostly for audio work, access to realtime-scheduling facilities you can use the Realtime-LSM module. Realtime linux security model takes advantage of the 2.6 series API developed for such things as SELinux to allow users under a certain group access to realtime performance.
Realtime Linux Security Module
The result of all this is that the linux kernel with full-fledged realtime-preempt applied and configured allows scheduled latencies of under 1msec, which is a drastic improvement over the standard kernel. This has dramatic impact for tasks that require a set latency for proper operation. The danger of realtime-lsm and running userlevel programs is that with sufficiently high priorities you can have a buggy program lock up your machine. For isntance I run the jack audio server program (jackd) at a priority of 65, which is higher then my IDE controller, which runs at a priority of 46.
One big is when musicians require set latency when using Linux as a OS in a digital audio workstation (DAW). It's important to have set latencies when your mixing music from a wide variety of inputs and it's very important to have low-latency responses. Anything under 7msec is considered non-noticeable latency by humans and since the software is only part of the latency caused by electronic music (you have the midi controller, the midi line, the sound card, and the synthizer for instance, each adding some latency) it's very important to get the latency as low as possible.
This is why I learned about all this realtime-preempt. I bought a new sound card a while ago, and just recently bought a midi piano-style keyboard controller to go with it. Before applying this patch I had to either set a high latency in my Jack audio server or suffer thru occasional squawks and cracks in the sound. Now with kernel 2.6.12-rc6-git1 with the realtime-preempt patches applied, and tweaks to the hardware (such as setting very high realtime-priority to my sound card's IRQ and increasing the PCI 'latency' (bus bandwidth) to 128) I can get reliable and clean operation down under 2msec of latency. This all functions perfectly well with a 'realtime' cpu load of 50-80 and system load peaking at 100. Depending on the application I have to give certain ones some low realtime scheduling priority of their own to have them keep up with the jackd service though. The only time I get xruns (errors in the audio stream) is when I start or close applications that automatically hook into jackd. The system is a 32bit 2ghz AMD Althon system (2400+) with a gig of ram. With a faster system you should be able to get even better results.
Of course this is not just for audio work, but should be of interest for any person desiring realtime operations. It's a potentially very attractive thing for embedded developers that would want the ability to run realtime operations but still be able retain the full-fledged capabilities (and code base) of a modern PC operating system.
This isn't the only set of patches that seek to get hard realtime capabilities to 2.6. For instance both Monta Vista and Fsmlabs have their own version of realtime linux 2.6, but since Ingor Molnar is a core developer his approach (and his approach is the least drastic without have to add new APIs) would be most likely to be accepted in to vanilla linux by Linus. Although it is very questionable if these capabilities will ever be permanently added to the 2.6 series kernel. The previous low-latency kernel patches from 2.4 series, in comparison, were never meant to be incorporated into Linux proper, but were just a way for audio developers to get the needed performance.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by drag © 2009-11-07 drag
When someone says: "I want a programming language in which I need only say what I wish done", give him a lollipop. (Alan J. Perlis)