NEW YORK—More than half of the 1.2 million lines of code for the real-time kernel technology have been moved into the mainline Linux kernel over the past year, Tim Burke, the director of emerging technologies at Red Hat, said at the Linux/Open Source on Wall Street conference here on April 23.
“The real-time upstream kernel work is a mainstream community initiative and is all about determinism and latency, about being able to have guarantees that transactions will complete within finite periods of time and that the highest priority processes and applications will be able to run without being pre-empted by lower priority applications or low level system services,” he said.
Red Hat had decided to drive this initiative forward some two years ago, and has been working on it since then. At its peak, this involved some 1.2 million lines of change and, over the past year, almost 50 percent of those patches have moved to the mainline kernel, Burke said.
Asked if all this code could create instability in the Linux kernel, Burke said “possibly,” but added that the code was robustly tested by Red Hat and the community before being added into the kernel incrementally, and had been extremely reliable so far.
After asking the small number of attendees if any of them were kernel developers—none were—Burke showed a performance chart that compared the standard Red Hat Enterprise Linux 5 (RHEL 5) kernel and replacing that with real-time RHEL 5, which is still under development by the company and designed to target financial services firms.
Most of the projects that drive real-time requirements involve messaging, and the goal of these real-time capabilities is to create predictability in response time and to ensure that the highest priority processes run first.
“The key challenge of getting this done is to remove black holes in the Linux kernel,” Burke said, noting that RHEL 5 real time showed a decrease in network latency compared to RHEL 5.
No application changes will be required to benefit from the real-time enhancements, and those applications which are latency bottlenecked due to kernel scheduling and interrupt handling, will see a benefit from this, he said.
But latencies introduced entirely in user space such as sub-optimal application codes and unbounded Java garbage collection were not eliminated, he said.
“There can also be downsides to real time, one of which is that average throughput might decrease. Real-time capabilities do not solve all the worlds problems. But, on the positive side, recompilation is not required,” Burke said.
John OHara, an executive director and distinguished engineer of investment bank technology at JP Morgan and the chairman of the AMQP (Advanced Message Queuing Protocol) working group, then took the stage to talk about the AMQP open standard for middleware.
“This open standard is different from others as it is a straightforward and complete solution for business messaging. It is cost effective for pervasive deployment, totally open, and created by users and technologists working together to satisfy real needs,” he said.
AMQP had been in development for more than three years before going public on June 20, 2006. Messaging middleware should provide event notification, message file transfer, meet real-world requirements of mission-critical systems, be trustworthy and provide a common infrastructure so that the enterprise AMQP can meet these requirements in one protocol, OHara said.
He added that AMQP protocol layering is network friendly; the infrastructure data is binary; it is independent of JMS (Java Message Service) and multivendor interoperable; and the “exchanges” define flexible routing rules.
“The AMQP model also provides common semantics: an exchange routes messages to a destination based on a set of rules,” OHara said.