Approaches to realtime Linux [LWN.net]

Approaches to realtime Linux

Posted Oct 13, 2004 22:45 UTC (Wed) by bluefoxicy (guest, #25366)
In reply to: Approaches to realtime Linux by karim
Parent article: Approaches to realtime Linux

NOTE: deterministic hard-rt is not about speed, it's about determinism. While Ingo's work is great at reducing latency, it cannot guarantee response times regardless of the load, kernel configuration, and driver set.

-- Karim Yaghmour

Purpose of the Project
The purpose of this effort is to to further reduce interrupt latency and to dramatically reduce task preemption latency in the 2.6 kernel series. Our broad objective is to achieve preemption latency bounded by the worst case IRQ disable.

-- http://source.mvista.com/linux_2_6_RT.html

Does this qualify? It's "bounded" yes? The bounding would qualify as true real-time, and the reduction of latency beyond that bound would just be a happy responsiveness bonus. Am I right? If not, please show err.

to post comments

Approaches to realtime Linux

Posted Oct 14, 2004 5:31 UTC (Thu) by karim (subscriber, #114) [Link]

Have you kept a count of the number of "reduce" and "broad objective" in that phrase?

Deterministic hard-rt is not about broad objectives or reducing latencies, it's about making guarantees. As it stands, MV's PR relies on slides that show graphs with maximum interrupt disable times, whereupon they can tell crowds: "Here, we have a hard-rt system, it's maximum latency is such as such and measured by our tools." That's just crap because no matter how large a sample is used for measurement (or how long the measurement session lasts) determinism is not about spikes in a graph, it's about mathemathically/algorithmically-demonstrable time-bound operation regardless of load and driver set, and reducing the latency by threading interrupts and introducing new locking primitives does not change the problem: The Linux kernel was never architectured to be a hard-rt deterministic kernel and the drivers shipped and the applications that run on it have never been meant to provide such behavior.

I've said this elsewhere, there is no path of incremental patches that can be applied to the kernel that will make it magically become deterministic. The kernel is meant to provide a best-case scenario for all the software it interacts with: drivers and applications alike. Deterministic hard-rt is all about making guarantees, both in terms of time and in terms of resources.

The greater question that beholds kernel developers is: can the Linux kernel be made to exhibit deterministic hard-real-time bevahior while keeping it fit for the development of mainstream drivers and applications?

Don't get me wrong, reducing latency is an extremely worthy goal, and I encourage any effort in that direction. However, as much as I trust the Linux kernel development community's inventivness and adaptibility to constraints, as much as I believe that providing the type of services required for applications with extreme time-dependencies is a goal that is not reconciliable with making the Linux kernel an inviting platform for driver and application developers.

Personally, I believe that the preemptability feature, which in reality is not yet actually used by most users out there for many reasons including stability, should be dropped altogether in favor of a simple infrastructure that allows time-sensitive applications to get what they need in a Linux environment: deterministic access to outside events. I believe the Adeos interrupt pipeline is the least intrusive and the most effective way of achieving this. It is a very small patch, it provides deterministic hard-rt, it can be built upon to provide a wide-range of services (RTAI/fusion being an example), and from the API useability point of view, it clearly stands out from the rest of the kernel API as being targeted for extreme outside-event-timing-responsiveness-sensitivity and is therefore much less likely to be used by accident by a driver or application developer.