Introduction to Real Time
Linux
1
Real-time versus Time Shared
Time sharing OS: (GPOS) attempt to
maximize system throughput.
Real time OS: (RTOS) attempt to
minimize latencies-either statistically
(soft) or worst case (hard)
2
RTLinux
A small hard real time operating system
Runs linux as its lowest priority task
RTLinux=RealTime+ Linux (two classes
of OSs working together)
3
The RTOS Design Paradox
A RTOS needs to be fast and predictable
so it needs to be small and precisely
designed.
Modern RT applications need
networking, GUIs, databases,
development environments, web
servers, and so on. In other words, the
OS must be rich with functionality.
But both of these conflict with each
other!! 4
Approach 1
Start with a small, simple, and fast RTOS. Add
features and functionality as needed.
Pros:
Achieves Hard real time performance!
Increase in determinism
GPOS features are available
Cons:
Slow (eg. millisec level)
Complex relation between drivers and software
All software and drivers must be hacked to work in
environment
Difficult to maintain and debug (costly)
5
Approach 2
Start with a big, powerful, complicated OS, and
add special RT processes:
Pros:
Achieve Soft Realtime performance!
Increased determinism
GPOS features are maintained
Cons:
Very Slow (eg. hundreds of milli-secs)
Complex relation between drivers and software
All software and drivers must be hacked to work in
environment
6
Difficult to maintain and debug (costly)
RTLinux approach
Start with small, simple, and fast RTOS. Add full
featured GPOS as lowest priority thread.
Pros:
Achieves Hard realtime performance!
both RTOS and GPOS are decoupled
each is optimized independently.
GPOS features are maintained
RTOS predictability reaches hardware limits (eg. tens
of micro-secs)!
Cons:
Realtime programming model must be altered.
7
RTLinux Advantages
Small RTOS (150kB!!)
Fast (micro-second level)
High degree of predictability (15 micro
sec jitter on x86)
All the sophisticated services are found
in the Linux thread 8
Design Scheme
A GPOS (Linux) is given a hardware
interrupt emulation layer (virtual
machine) so it cannot disable interrupts.
the RTOS decides when to pass
interrupts to the GPOS
RT applications cannot be delayed by
non-RT software! 9
RTLinux-Block Diagram
10
GPOS view of RTLinux
11
RTLinux view of GPOS
12
RTLinux view of GPOS
13
Non RT Kernel
14
RT Linux Kernel
15
RTLinux Kernel Linux is executed in the background
User Processes
Real Time Tasks System libraries
Device drivers Linux kernel
I/O Software Interrupts
Direct
h/w RT-Scheduler
access RTLinux Plug-in
I/O Hardware Interrupts
Hardware
16
RTLinux Advantages
Performance nears hardware limits. Ex: on a fully
loaded machine (compiling the Linux kernel, running
Netscape, and a ping flood), the worst case jitter on
a periodic task running at 1ms, 24 hour test:
Pentium4/Athlon: 13 micro sec
Dual Pentium 4: 16 micro sec
G4: 15 micro sec
tiny footprint (150kB)
standardized API POSIX threads and signals
uses all of the Linux functionality without interfering
with the mainstream Linux Development
17
RTLinux Advantages contd..
no scheduling interactions with the GPOS
no dependencies between RTOS and GPOS except by
programmer choice
The split design encourages a safe programming
style with clear separation between hard RT and
soft/non-RT
Use any third party software. Examples:
databases: Oracle, DB2, MySQL, PostgreSQL etc.
editors: emacs, vi, jove etc.
graphical toolkits: GTK+, Qt etc.
18
RT Linux – Tasks
Initial Design – Each RT task executed in its
own address space.
High overhead of context switching as TLB
had to be invalidated.
High overhead of system calls.
Now all RT tasks run in the same address
space (in the kernel space) and at the highest
privilege level.
But highly error prone as a bug in a single
application can wipe out entire system.
19
RT Linux – Tasks (Contd.)
RT tasks run as kernel modules. Can be
dynamically added.
Tasks have integer context for faster context
switching (unless FP context is explicitly
requested).
Hardware context switching provided by x86
is not used.
Task resources should be statically allocated
(kmalloc etc. should not be used within an RT
task).
20
RT Linux - Scheduling
RT Linux is module based – the
scheduler is itself a loadable kernel
module.
Default – A simple preemptive priority
based scheduler where the tasks are
statically assigned priorities. The
highest priority task ready to run is
scheduled.
Cooperative Scheduling 21
RT Linux – Scheduling
(Contd.)
Alternate scheduling policies
Earliest Deadline First (EDF) – A dynamic priority
scheduler in which the task with the nearest
deadline is scheduled.
Rate Monotonic (RM) – A static priority scheduler
for periodic tasks where the task with the smallest
period is assigned the highest priority. This is
provably the optimal policy.
ADS-Application Defined Scheduler
22
Design of applications using
RT Linux
It is envisaged that applications will
consist of two parts.
The Real Time part should be fast,
simple and small.
Other part will run in user space and
should take care of I/O etc.
User task will communicate with real
time task via real time fifos.
23
Structure of RT Application
RT Fifo
User Process
RT Fifo
X Windows Linux Kernel
RT Process
Display Disk Network
Peripheral Device
24
Conclusion
RT Linux has achieved hard real-time
performance by making minimal changes to a
freely available Operating System.
Provides an alternative to proprietary real-
time systems which may be prohibitively
expensive.
As Linux develops, RT Linux will also ride the
wave of its development.
Unlike other RT systems, no separate support
for RT Linux is needed since support for Linux
is already widely available. 25
RTLinux Demonstration
26