Real-Time Linux: What Is Next?
summary
PREEMPT_RT work is essentially upstream now after an eight‑year effort with $5.7M raised and many features like high‑res timers, tracing and threaded IRQs merged; remaining core patches are tiny (printk). A long‑running throttling problem affects 95% busy‑loop runs and the current fix is to boost the CFS by wrapping it in a SCHED_DEADLINE reservation while avoiding priority inversion; that change is in active development. Tooling matures too — rtla merged after 12 years — and isolated‑CPU tuning proves sub‑10 µs latency in practice.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:26Real-time community motivation
- 2:09PREEMPT_RT upstreaming progress
- 6:23Why avoid shortcuts
- 7:07Real-time throttling explained
- 10:38PREEMPT_RT impact on kernel
- 12:45Architecture benefits
- 13:06PREEMPT_RT benefits beyond real-time
- 15:11Real-time community next steps
- 17:57Priority inheritance explained
- 20:30Real-time in industrial safety
- 21:36SCHED_DEADLINE status
- 23:46Getting involved and improving documentation
- 26:16rtla and tracing tools journey
- 29:07Need for diagnostics guides
- 31:34Messaging challenges
- 35:48Documentation gaps
- 40:49Dynamic kernel parameters
- 43:14Kernel thread priorities
- 45:41AI tools for real-time
related talks
26mReal-time Linux: what is next?
42mBoF: Realtime Linux
50mInside the RT Patch
51mReal Time is Coming to Linux; What Does that Mean to You?
01h 08mRT Linux in Safety Critical Systems: the potential and the challenges
40mRT Linux in Safety-Critical Systems: The Potential and the Challenges
53mPREEMPT_RT - How Not to Break It.
35mPreempt-RT Raspberry Pi Linux