Victor Yodaiken, creator of RTLinux, has provided a brief statement about MontaVista Software's recent press release entitled “MontaVista First to Deliver Hard Real-Time Linux.” (MontaVista, it should be noted, supports both RTLinux and the new kernel preemption technology.) In his response, Yodaiken draws significant… distinctions between the architectural approaches taken by each (RTLinux; kernel preemptability), provides a technical perspective on the usefulness of each, and mentions some issues that need to be considered in proceeding along a kernel preemption path. Yodaiken writes . . .

There have been several efforts to change the Linux kernel to offer support for some level of real-time response. RTLinux takes a very different approach so that we get microsecond level real-time response without changing Linux internals. RTLinux puts a hard real-time process outside of Linux and lets users install real-time threads and signal handlers in this process. The real-time process runs when it needs to and does not interact with the Linux kernel at all: it is not scheduled by the Linux scheduler, it does not use Linux system calls, it cannot be delayed by Linux attempts to turn off interrupts (which we catch and emulate). Real-time software can communicate with Linux through fifos, shared memory, or signals but still gets hardware speed interrupt latencies, RTLinux worst case interrupt latencies are 15 microseconds on a generic x86 and better on PowerPC and Alphas.

A whole class of RTLinux applications would certainly benefit from having millisecond latency processes available in the Linux kernel — as long as the kernel didn't lose speed or reliability along the way. But it is important for people to realize that the Linux kernel is, and should be, designed to optimize average case behavior not the worst-case behavior we worry about in real-time programming. For example, Linux spends some time reordering and combining block I/O requests so that, on average, disk I/O is faster — but, this may slow down an individual request. Similarly, Linux “swap out” code locks the whole system up so that it can efficiently scan through all the pages that may need to be written out in one pass. Other uses must wait for this scan to finish but the intention is that as a result the system spends less total time in the swap-out code. When you make Linux internals “low latency” you have to make sure that you don't slow the system down too much and you have to make sure that every kernel change, and every new or revised driver, does not introduce any new long latencies. Many of us look at the example of the SGI IRIX operating system, which is pre-emptive, slow, and hard to maintain, as a cautionary example.

Related stories:
MontaVista unveils fully preemptable Linux kernel prototype
Victor Yodaiken on the past, present, and future of RTLinux
Lineo responds to MontaVista “hard real-time Linux” claims

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.