Traveling in Real Time

So I am hitting the road next week. It should be no surprise that LinuxCon and the Linux Plumbers Conference are coming up. I have a talk (the well-travelled Kernel Report) and the kernel developers’ panel, both on Monday; I fully expect to be tired by the end. There’s a lot of other interesting stuff happening at LinuxCon, which is being held for the first time ever. I’m looking forward to seeing how it comes out.

The Linux Plumbers Conference is happening for the second time. The first was a great success – by most accounts, one of the very best technical events of the year. Quite a bit of serious work got done there, with effects being felt throughout the development community. This year – which has just sold out – looks to be just as good.

Unfortunately, I’ll be skipping out of Plumbers early. Fortunately, it’s for an event that I’m looking forward to at least as much: the Realtime Linux Workshop in Dresden, and the Realtime mini-summit which precedes it. These, too, will be events which strongly influence future Linux development.

“Realtime,” of course, means that the system can be counted on to respond to external events within a known, bounded time. When one thinks of realtime applications, it’s natural to envision serious data acquisition and process control applications. These applications do exist, but realtime Linux is applicable to a far wider field than that. Embedded devices Рespecially gadgets like telephones Рcan make good use of realtime response, for example.

Perhaps the area receiving the most commercial attention, though, is in the financial trading realm. If you’re letting your computers make decisions that move millions of dollars around based on immediate market conditions, you really want to know that the computer will get the job done in the required time. The alternative can be a lot of lost money. When you realize that much of that high-speed trading is done on Linux systems, you come to see why realtime Linux is so interesting to financial businesses. My (very much outsider) understanding is that many of the customers of the realtime distributions are coming from this sector.

Getting true realtime response out of a general-purpose operating system has long been held to be impossible. So realtime has traditionally been done on small, special-purpose kernels which have been heavily audited to ensure that no unwanted latencies will sneak in. Linux kernel developers have never been much interested in being told something is impossible, though. So, a few years back, a group of them set out to create a version of the Linux kernel which could be counted on to provide realtime response.

This work was done by making (almost) everything in the kernel preemptible. When any part of the system can be pushed out of the way to deal with an important event, it is much harder for specific parts of the kernel to create unexpected latencies. This approach (called “realtime preemption”) greatly reduces the amount of code auditing which must be done.

Realtime Linux works well Рat least, on hardware which is, itself, properly responsive. It has been packaged into enterprise-level realtime offerings by a number of distributors and appears to be a big business. But there is one interesting note to all of this: much of the realtime code is outside of the mainline kernel. This is a violation of the “upstream first” rule which is normally followed quite strictly by most distributors.

There is a good reason for this: the realtime work is a big set of changes to the kernel. It could never have been just dumped into the kernel in the course of a normal three-month development cycle without destabilizing things badly. So the realtime code has stayed outside of the mainline while it evolved and stabilized; pieces of it have been merged over the years as they proved ready. Many features of the current kernel – which improve things for all users – have their origins in the realtime tree.

At this point, though, the realtime developers think that they are getting close to done Рat least, as close to “done” as anything ever gets in the constantly-evolving Linux kernel. So it’s time for most of the rest of this code to move out of the realtime tree and into the mainline. One of the primary goals of the mini-summit in Dresden is to put together a strategy for making this happen. If this process works, we should see the addition of this major functionality mostly complete sometime in 2010.

The main realtime conference, instead, is dedicated to the state of the art. Yes, I’ll be doing the Kernel Report talk again Рthough I think I’ll take out the realtime slides since Thomas Gleixner will have provided a much better update just before me. Then we’ll get to hear what people are doing with realtime Linux, how things can be improved, and what the developers are planning.

It looks to be a fascinating, exhausting experience. Years of work are coming to their culmination now, and all Linux users will benefit from it.