This document discusses the challenges of real-time computing on Linux and potential solutions. Real-time means very low maximum latency, below 100 microseconds. While Linux was not designed for real-time, it is now used in many embedded systems. Options to address real-time include using separate hardware, a hypervisor with an real-time operating system (RTOS), asymmetric multiprocessing (AMP) with an RTOS, or solutions within Linux like PREEMPT_RT that adds preemption and CPU isolation techniques to reduce worst-case latency without changing applications. The document reviews these approaches and notes that real-time remains an important area as Linux is increasingly used in embedded systems.

1. Overview of
Linux
real­time
challenges
June 1, 2013

2. Daniel Stenberg
Email: daniel@haxx.se
Twitter: @bagder
Web: daniel.haxx.se
Blog: daniel.haxx.se/blog
●
Free Software
●
Network hacker
●
Embedded developer
●
Consultant

3. Agenda
What's real-time in this context?
Why is real-time still a concern?
Ways to deal with the problem
• Off to secondary hardware
• Hypervisor or AMP
• PREEMPT_RT
• CPU isolation and dynamic tick
Future?

4. Real­time
Real-time can mean a lot of different
things to different audiences
• Low maximum latency: below 100 us,
sometimes down to 20us
• Very low risk of every breaking that

5. Why is this a concern
2013?
• Plain Linux wasn't designed to deal with low latency
• A move towards "commodity" hardware - less
special stuff means solving the problems in general
CPUs
• Linux everywhere: RTOS-solutions get moved over
from legacy systems to Linux-based
• Still a lot of stacks and applications that act in CPU
but needs to respond fast and accurately
• Sometimes a bit more requested than perhaps can
be technically motivated

6. What are the options?
Linux is a given.
What magic can you apply to a system
to address the problem of a low
maximum latency?

7. Separate dedicated HW
• A tested and proven way
• A separate small chip (with an
RTOS?) for just the time critical stuff
• ... or an FPGA
• But it adds system complexity and
price

8. Hypervisor with RTOS
• Isn't pure Linux
• Adds complexity
• Usually proprietary
• May reach really low latencies
One or more cores

9. AMP with RTOS
• Isn't pure Linux
• Adds complexity
• Often proprietary
• May reach really low latencies
Core 0 Core 1 Core 2 Core 3

10. The more pure Linux
solutions
1 ­ Address and lower the worst
case
2 ­ Avoid hitting the worst case

11. PREEMPT_RT
●
An off­mainline patch since 10+ years!
●
Add preemption to lower max latency
●
replace kernel spinlocks with mutexes
●
move interrupts and software interrupts to kernel
threads
●
works on single core systems
●
Changes behavior and requires drivers to be tested
●
User­space is the same

12. CPU isolation 1/2
●
NOHZ, dynamic tick
●
Isolated cores == without ticks do nothing!
●
Only one thread allowed!
●
Avoiding the kernel is hard
●
Approaching mainline (3.10)
●
Requires rethinking user­space

13. Linux kernel
Core 0 Core 1 Core 2 Core 3
CPU isolation 2/2

14. Future
●
Real­time and latency remain
interesting
●
PREEMPT_RT is not in mainline
●
NOHZ is just getting in
●
We create the future!

15. (from UBM Tech Electronics' Embedded Market Survery)

16. Work with this at Enea

17. Thank you
Daniel Stenberg <daniel@haxx.se>