Emerging Technologies: Developments in Red Hat Enterprise Linux RealTime

by Emerging Technologies Team

You may have heard the news from Red Hat’s CTO Brian Stevens’ keynote at the Red Hat Summit that we are building a realtime variant of Red Hat Enterprise Linux. There were a few sessions at the Summit describing our initiative in more detail. For those of you who weren’t present, we’d like to share some realtime info with you here.

We can simplify the primary functional objectives of our realtime initiative down to a few key points:

1. Determinism: provide consistent, repeatable response times
2. Priority: ensure the highest priority processes run first

Sounds rather basic, right?

For most workloads, a properly tuned Red Hat Enterprise Linux kernel (in RHEL 2.1, 3, 4 or 5) meets customer requirements. Typical timing requirements are in the range of millisecond response time. However for the most demanding customer workloads, the requirements are in the microsecond range. To give just a few representative examples:

* Financial Services industry: here time is money. In this highly competitive market, shaving fractions of a second off the time it takes to performs market analytics yields huge advantage. Additionally, there are increasing government regulations for consistency in trading. They don’t want things smelling fishy if some trades take longer than others.
* Federal command and control systems: here, “close enough” isn’t good enough. They need to dependably know that the highest priority application threads will run and complete in predictable periods of time.

The primary reason why the standard Red Hat Enterprise Linux products can’t completely meet the most demanding response time requirements is because there are numerous lengthy kernel codepaths which are non-preemptable. Without getting too technical here, this means that while these non-preemptable kernel codepaths are running, the high priority application threads are not running. Hence these long-running kernel codepaths result in delays in the application running, which is the cause of inconsistent response times (also referred to as non-determinism). In his keynote address at the Summit, Brian displayed a performance chart illustrating that when running a messaging workload on standard Red Hat Enterprise Linux, there was substantial deviation in response times. Whereas when running the realtime kernel, the response times were highly consistent.