BAS + ECE February 2015 - page 42

February 2015
42
O
perating
S
ystems
Mainline Linux goes real-time
... really?
By Dr. Carsten Emde,
OSADL
Only a few people know
that about 90% of the code
to make Linux a real-time operating
system has already been merged into
mainline Linux. The remaining 10%
is maintained as off-tree patches
requiring immense work. Mainline
consolidation of these is the order of
the day. All real-time Linux users are
called on to contribute.
„„
Since the end of the 90s, plans have existed
to turn Linux into a real-time operating sys-
tem. One of the reasons for this was the rapidly
accelerating speed of innovation in informa-
tion technology. At the time, the available
dedicated RTOS kernels had to be individ-
ually retrofitted each time a new technology
swept the market. The effort that this required
was enormous, and the delay in availability of
the new technologies for industrial systems
was increasingly criticized by users. This led
to the realization that it would make more
sense over the long term to turn a general pur-
pose operating system kernel into a real-time
operating system kernel than to repeatedly
equip all RTOS kernels with the technologies
of general purpose operating systems.
However, this was no easy undertaking. Many
respected operating system experts at the time
felt that it was impossible to render an oper-
ating system real-time capable as an after-
thought. However, the open structure and
flexibility of well-coordinated open source
development, as in the case of the Linux kernel
development, made this feasible even though
it was a daunting task. Among those who took
up the challenge, were: Doug Niehaus, Profes-
sor at Kansas University, USA, Ingo Molnár
for Red Hat, Thomas Gleixner, CEO of Linu-
tronix, for several clients, Paul McKenney for
IBM, and Steven Rostedt for Red Hat.
After the basic components were developed
from 2000 to 2006, they were gradually
merged into the mainline Linux kernel, a task
that is about 90% completed. The remaining
10% are available as the so-called PREEMPT_
RT patch which have been maintained and
adapted byThomas Gleixner and his coworker,
Sebastian Siewior, at Linutronix. In addition,
Steven Rostedt is taking care of the real-time
capabilities of the long-term versions 3.2,
3.4, 3.10, 3.12 and 3.14. The PREEMPT_RT
patch supports more architectures and sub-
systems and is more closely linked with main-
line development than any other method for
achieving real-time for Linux.
Once the mainline Linux kernel has been
equipped with real-time capabilities and is
appropriately configured, a real-time oper-
ating system will be available that is largely
capable of coping with established RTOS ker-
nels in many ways. The two key benefits of a
real-time mainline Linux kernel are guaran-
teed real-time features for the vast majority
of industrial systems, and an API exclusively
based on the POSIX standard. The fact that
the response behaviour of such a real-time
Linux kernel is predictable and can actually
be guaranteed has been confirmed by long-
term measurements at the test center of the
Open Source Automation Development Lab
(OSADL) in which 100 million trigger pulses
per test system are evaluated daily under dif-
ferent stress and load scenarios. The results
were depicted in sequential latency plots
(figure 1). The logarithmic scaling of the fre-
quency values in the y-direction make it pos-
sible to visualize even a single outlier. As can
be seen in an example measurement, not a
single outlier arose in over 60 billion cycles.
The maximum measured latency of the 2700-
MHz Intel processor of around 20μs is about
that which is achieved by dedicated RTOS
kernels.
Despite the impressive success of the real-
time Linux kernel, we should not loose sight
of the fact that this software development
requires a functioning ecosystem, as is the
case with other components of the Linux
kernel and open source software in general.
Such an ecosystem works like a charm when
the Linux kernel is used in servers, smart-
phones, and especially in telecommunications.
Figure 1. Sequential latency
plots of 100 million test cycles
1...,32,33,34,35,36,37,38,39,40,41 43,44,45,46,47,48,49,50,51,52,...56
Powered by FlippingBook