Linux Section

Realtime-Preempt for the Linux kernel.

Author: drag
Date: Sat Jun 11 08:49:58 2005
Subject: Realtime-Preempt for the Linux kernel.

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 avaible here:
http://people.redhat.com/mingo/realtime-preempt/older/ANNOUNCE-voluntary-preempt

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:
http://people.redhat.com/mingo/realtime-preempt/

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)

and

Thread Softirqs
Thread Hardirqs
Thread RCU
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:
http://www.rdrop.com/users/paulmck/rclock/

A kerneltrap story:
http://kerneltrap.org/node/3995?PHPSESSID=4bc02ae16e5a27308031f3cd664fd574

A couple wikis on the subject:
http://www.affenbande.org/~tapas/wiki/index.php?Low20latency20for20audio20work20on20linux202.6.x
http://tree.celinuxforum.org/CelfPubWiki/RealtimePreemption

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.

http://www.muse-sequencer.org/wiki/index.php/Realtime-lsm_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 this page was useful to you, please click to help others find it:  
Your +1's can help friends, contacts, and others on the web find the best stuff when they search.

2 comments

More Articles by drag

Site map | Disclaimer
"Realtime-Preempt for the Linux kernel." Copyright June 2005 drag

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.