Linux: Zentrale Echtzeit-Patches nach 17 Jahren integriert
Der offizielle Kernel enthält jetzt die Kerntechnik, um Realtime-Anforderungen zu erfüllen. Weil noch Arbeiten ausstehen, sind sie aber noch nicht aktivierbar.
![](https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/1/7/2/7/9/3/shutterstock_766847608-ea8a9c6016d1874a.jpeg)
(Bild: Min C. Chiu/Shutterstock.com)
Das Herzstück der Echtzeitunterstützung für Linux hat es endlich in den offiziellen Kernel geschafft. Nach wie vor lässt sich der Realtime-Support dort aber nicht aktivieren, denn es gibt noch einige mittelgroße und allerlei kleine Baustellen. Über diese Dinge haben Entwickler des durch Geldmangel in die Länge gezogenen Projekts auf der derzeit stattfindenden Linux Plumbers Conference 2021 diskutiert. Dort kam auch schon zur Sprache, wie sie das Ganze in Zukunft instand halten wollen.
Herzstück ist gelandet
Ein enorm wichtiges Etappenziel hat die Echtzeitunterstützung für den Linux-Kernel am vorletzten Augusttag erreicht: Linus Torvalds hat das Gros der für ordentlichen Realtime-Support erforderlichen Locking-Infrastruktur in den Hauptentwicklungszweig von Linux integriert. Diese war bislang Herzstück des "RT Kernels" (auch als "RT Patch" oder "RT Zweig" bekannt), in dem die Entwickler des PREEMPT_RT-Projekts seit langem die Quellcode-Patches sammeln, pflegen und verbessern, die Linux zu Echtzeiteigenschaften verhelfen.
Die aufgenommenen Änderungen an Locking-Techniken wie Spinlocks, Mutexes und Rwlocks sind letztlich der Kern des Ganzen, mit dem PREEMPT_RT im Herbst 2004 noch unter anderem Namen begonnen hat. Die jetzt integrierten Anpassungen summierten sich auf satte siebzig Patches. Durch sie kann ein mit Realtime-Support kompilierter Kernel nahezu alle von ihm erledigten Aufgaben jederzeit ohne größere Verzögerung unterbrechen, um sich vorübergehend Wichtigerem zu widmen.
Für Echtzeitsupport ist das entscheidend: Linux kann sich so jederzeit schnell Programmen zuwenden, die eine bestimmte Aufgabe immer in einer vorher definierten Zeit erledigen müssen – also auch, wenn etwas Unwichtiges das System gerade stark fordert und so widrige Umstände schafft. Welche Programme der Kernel bevorzugen soll, legt eine Markierung am Prozess fest. Für viele PCs und gerade Server ist derlei aber uninteressant, denn durch die höhere Reaktionsfreude werden andere Aufgaben häufiger unterbrochen und laufen so langsamer.
Zweiter Meilenstein nur wenige Tage später
Durch das PREEMPT_RT-Herzstück kann sich Linux zwar an deutlich mehr Stellen unterbrechen, aber das allein reicht nicht: Einige Codebereiche muss der Kernel in einem Rutsch ausführen, um die Integrität der aktuell verarbeiteten Daten in Mehrprozessorsystemen sicherzustellen.
Zahlreiche zu längeren Wartezeiten führende Areale dieser Art gab es beim SLUB Memory Allocator, der Kernel-intern kleine Bereiche des Arbeitsspeichers bereitstellt. Die Ursachen dafür hat eine Serie von über 30 Patches beseitigt, die Torvalds wenige Tage nach den Locking-Änderungen in den Hauptentwicklungszweig von Linux integriert hat.
Die Anpassungen werden dadurch in Linux 5.15 enthalten sein, das zum 1. oder 8. November erscheinen sollte. Dessen Code enthält auch bereits bei Linux 5.3 integrierte Grundlagen zum Aktivieren des Realtime-Supports. Dennoch ist die Option beim Kompilieren eines Kernels weiterhin nicht aktivierbar.
Eine große und allerlei kleine Baustellen
Das liegt an anderen ununterbrechbaren Stellen des Linux-Codes, die bekanntermaßen noch zu unerwünscht langen Wartezeiten führen, die beim Echtzeiteinsatz stören würden. Eine davon ist die Printk-Infrastruktur, über die der Kernel Log-Meldungen annimmt und ausgibt. Die PREEMPT_RT-Entwickler haben die Lage dort im letzten Jahr erheblich verbessert und eine weitere wichtige Änderung in Linux 5.15 integrieren können; zugleich stehen weitere Arbeiten aber noch aus. Details dazu finden sich in den Folien und der Videoaufzeichnung eines Vortrags, den der Entwickler hinter den Umbauten am Dienstag auf der Linux Plumbers Conference 2021 gehalten hat.
Neben den Printk-Arbeiten gibt es noch viele kleine Baustellen. Das zeigt sich beim Blick auf die Vorabversion des Realtime-tauglichen Linux 5.15-rt, für die die Entwickler jetzt "nur noch" 175 Patches anwenden, zirka 215 Dateien ändern und dabei 1350 Zeilen einfügen und 2650 entfernen – das sind rund hundert Patches weniger als noch bei Linux 5.14-rt (260 geänderte Dateien, 3700 eingefügte Zeilen, 7450 entfernte Zeilen). Manche der Patches sind allerdings nur für bestimmte Einsatzgebiete oder Prozessorarchitekturen relevant.
Zeitrahmen bleibt ungewiss
Über einige dieser und weiterer Baustellen haben die Entwickler am Dienstag im Rahmen eines Status-Überblicks zu den RT-Patches diskutiert. Dort wurden mit "cpu_chill()" und NOHZ-Verhalten zwei weitere mittelgroße Baustellen angesprochen. Zwischen den Zeilen war aber zu hören, dass selbst die Entwickler keine Prognose wagen, wie lange es noch dauert.
Letztlich bleibt damit ungewiss, ob noch Monate oder aber Jahre vergehen werden, bis alle wesentlichen Änderungen in den Hauptentwicklungszweig von Linux einziehen – obwohl es schon 2018 und 2019 hieß, dass es bald soweit sein würde, letztlich aber doch anders kam. Teilweise wurden Probleme schlicht unterschätzt. Ein großes Problem war und ist aber immer wieder Geldmangel: Obwohl viele Firmen die RT-Kernel nutzen, beteiligen sich nur relativ wenige aktiv an der Entwicklung oder schießen Geld zu. Zentrale PREEMPT_RT-Entwickler mussten daher schon mehrfach Arbeiten an den Realtime-Patches zurückstellen und sich anderen Aufgaben widmen, um ihre Brötchen zu verdienen.
Pflege heute und morgen
In der Statusdiskussion und im Vortrag Maintaining PREEMPT_RT: now and then (Folien, Aufzeichnung) ging es zum Teil schon darum, wie es mit der Pflege des Realtime-Supports weitergehen soll, wenn alles Wesentliche im offiziellen Kernel enthalten ist. Denn unbedarfte Änderungen an irgendwelchen Stelle von anderen Entwicklern könnten die Realtime-Eignung massiv stören. Die Finanzierung der dazu benötigten Entwicklerressourcen dürfte daher auch in Zukunft die Entwicklungsgeschwindigkeit und die Qualität der Echtzeitfähigkeiten von Linux beeinflussen.
(ovw)