# Real-Time Linux: Deep Dive in PREEMPT_RT

TL;DR / Management Summary Standard-Linux ist auf Durchsatz optimiert, nicht auf garantierte Antwortzeiten. Ein Real-Time Kernel (PREEMPT_RT) ändert das Prioritäts-Modell des Kernels fundamental. Durch das Umwandeln von Interrupt-Handlern in Threads und das Ersetzen von Spinlocks durch schlafende Mutexes wird der Kernel fast vollständig unterbrechbar. Ziel ist es, die Worst-Case-Latenz zu minimieren – essentiell für Audio-Bearbeitung, industrielle Steuerungen und High-Frequency Trading.

# 1. Einführung & Architektur

Durchsatz vs. Determinismus.

Ein normales Linux-System kann extrem schnell sein, aber es gibt keine Garantie, dass ein Task immer innerhalb von z.B. 100 Mikrosekunden ausgeführt wird. Ein Kernel-Lock oder ein langer Interrupt-Handler kann die CPU blockieren.

# Was macht der PREEMPT_RT Patch?

  1. Threaded IRQs: Hardware-Interrupts werden nicht sofort “hart” abgearbeitet, sondern in Kernel-Threads verschoben. Diese können priorisiert und unterbrochen werden.
  2. Sleeping Spinlocks: In einem RT-Kernel blockieren Locks den Task nicht “aktiv” (Busy Loop), sondern lassen ihn schlafen, sodass andere hochpriore Tasks laufen können.
  3. Priority Inheritance: Verhindert das Problem der Prioritätsinversion (wenn ein niedriger Task eine Ressource hält, die ein hoher Task braucht).

# Architektur-Diagramm (Mermaid)

graph TD
    subgraph "Standard Kernel"
    HW_IRQ[Hardware IRQ] -->|Blocks everything| Handler[Long ISR Handler]
    Handler -->|Done| Task[User Task]
    end

    subgraph "Real-Time Kernel (RT)"
    HW_IRQ_RT[Hardware IRQ] -->|Quick Trigger| IRQ_Thread[IRQ Thread - Pri 90]
    IRQ_Thread -.->|Can be preempted| RT_Task[Critical RT Task - Pri 99]
    end

# 2. Installation & Vorbereitung

Den RT-Kernel backen.

Viele Distributionen bieten fertige RT-Kernel an (z.B. linux-rt auf Arch, kernel-rt auf RHEL).

# Manuelle Kompilation (Konzept)

Wenn Sie den Patch selbst anwenden:

  1. Kernel-Source und passenden Patch von kernel.org laden.
  2. patch -p1 < patch-X.Y.Z-rtN.patch
  3. In make menuconfig unter General Setup -> Preemption Model:
    • Wählen Sie: Fully Preemptible Kernel (Real-Time).

# 3. Deep Dive: System Tuning für Real-Time

Mehr als nur ein Kernel.

Ein RT-Kernel allein reicht nicht. Das System muss “ruhig” gestellt werden.

# CPU Isolation

Verhindern Sie, dass der Standard-Scheduler normale Prozesse auf Ihre RT-Kerne schiebt.

# Boot-Parameter in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="... isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3"

Hier werden die Kerne 2 und 3 exklusiv für RT-Anwendungen reserviert.

# Interrupt Pinning

Schieben Sie alle Hardware-Interrupts (außer denen für Ihre RT-Anwendung) auf Kern 0 oder 1.

# Beispiel: Alle IRQs auf CPU 0
for i in $(ls /proc/irq/); do
    echo 1 > /proc/irq/$i/smp_affinity
done

# 4. Day-2 Operations: Latenz messen

Vertrauen ist gut, cyclictest ist besser.

# Latenz-Test mit rt-tests

# Misst die Abweichung vom idealen Scheduling-Zeitpunkt
cyclictest -l1000000 -m -n -a2 -t1 -p99 -i200

# 5. Troubleshooting & “War Stories”

Wenn Real-Time das System einfriert.

# Top 3 Fehlerbilder

  1. Symptom: Das System reagiert nicht mehr, CPU-Last 100%.

    • Ursache: Ein RT-Task (Priorität 99) ist in einer Endlosschleife. Da er wichtiger ist als die Shell oder der SSH-Dienst, bekommt nichts anderes mehr Rechenzeit.
    • Lösung: Nutzen Sie RT Throttling (/proc/sys/kernel/sched_rt_runtime_us), um 5% CPU für Management-Tasks zu reservieren.

  2. Symptom: Unerwartet hohe Latenz-Spikes.

    • Ursache: SMI (System Management Interrupts) vom BIOS/UEFI. Diese sind für den Kernel unsichtbar.
    • Lösung: BIOS-Tuning (Disable Power Management, SpeedStep, C-States).

  3. Symptom: Kernel Panic im RT-Modus.

    • Ursache: Ein Treiber ist nicht RT-safe (nutzt ungültige Locks in einem Threaded Context).

# “War Story”: Der klickende Sound

Ein Audio-Streaming-Server hatte alle 10 Minuten kleine Aussetzer. Wir nutzten den RT-Kernel und cyclictest. Die Entdeckung: Der Grafikkartentreiber führte im Hintergrund ein thermisches Management durch, das die CPU für 500 Mikrosekunden sperrte. Durch CPU-Isolation und Deaktivierung der GPU-Hardware-Beschleunigung konnten wir die Latenz stabil unter 20 Mikrosekunden halten.

# 6. Monitoring & Metriken

RT-Status im Dashboard.

# Wichtige Metriken

# 7. Fazit & Empfehlung

Real-Time Linux ist eine Nische für Spezialisten.

# Anhang: Cheatsheet

Befehl Zweck
uname -a Prüfen auf “PREEMPT RT” String
chrt -f -p 99 <pid> Priorität eines laufenden Prozesses auf RT setzen
hwlatdetect Suche nach Hardware-induzierten Latenzen
tuna GUI/CLI Tool zum bequemen CPU/IRQ Pinning

# Referenzen