Nach 20 Jahren mühevoller Arbeit: Linux-Kernel jetzt Echtzeit-tauglich

Inhaltsverzeichnis

Nach zwei Jahrzehnten und zehntausenden Änderungen allerorten hat eine Gruppe von Entwicklern endlich ihr Ziel erreicht: Seit Freitag dieser Woche bringt der offizielle Linux-Kernel alles mit, um harte Echtzeitanforderungen erfüllen zu können. Sprich, selbst unter widrigen Umgebungsbedingungen führt er eine vorher definierte Aufgabe garantiert in der festgelegten Zeit aus. Derlei ist beispielsweise für viele Roboter in der Industriefertigung oder selbstfahrende Gefährte essenziell; zugleich ist es aber auch förderlich für die latenzarme und ruckelfreie Verarbeitung von Audio und Video sowie zahlreiche andere Einsatzgebiete. Gemeinhin hieß es in der Forschung jahrzehntelang, es sei unmöglich, harte Echtzeit mit einem General-Purpose-Betriebssystem wie Linux zu realisieren.

Die Realtime-Fähigkeiten erreichen Nutzer am 18. oder 25. November mit Linux 6.12, sofern bis dahin nicht etwas Unvorhergesehenes passiert. Die Standard-Kernel gängiger Linux-Distributionen werden dennoch sicher weiter keinen harten Echtzeit-Support bieten. Der jetzt erreichte Meilenstein bedeutet zudem mitnichten, dass Linux jetzt harte Echtzeitfähigkeiten aus X-beliebiger Hard- und Software herauskitzelt. Keineswegs abgeschlossen ist auch die Arbeit der Entwickler, die den PREEMPT_RT-Patch und andere für den Realtime-Support wichtige Änderungen jahrelang im RT-Tree vorangetrieben haben. Doch der Reihe nach.

Auf den letzten Metern wurde es noch mal zäh

Reaktionszeiten von 100 Mikrosekunden soll Linux durch den neuen Realtime-Support garantieren können, heißt es aus Entwicklerkreisen – gängige und für den Echtzeiteinsatz geeignete ARM64-, RISC-V oder x86-64-Plattformen vorausgesetzt. Durchschnittlich seien dort sogar 10 Mikrosekunden drin.

Die letzte größere, dazu nötige Änderung waren die letzten Umbauten der Printk-Infrastruktur, die schon am Dienstag für Linux 6.12 übernommen wurden. Über Letztere nimmt der Kernel die etwa per dmesg abrufbaren Log-Meldungen an, um sie dann über virtuelle oder serielle Konsolen auszugeben.

Wenn es mit dem Kernel irgendwo hakt, ist dieses Log oft die essenzielle Hauptinformationsquelle. Um parallel eingehende Nachrichten dabei nicht zu einem Kuddelmuddel zu vermischen, ist Synchronisation enorm wichtig. Bei der drehte sich der Printk-Code allerdings bislang gerne mal um sich selbst, was die Ausführung von anderen parallel laufenden, aber wichtigeren Programmen verzögert hat. Genau das darf etwa bei einem selbstfahrenden Lagerroboter nicht passieren, denn sonst nimmt der eine Kurve womöglich einen Tick zu spät und reißt dabei ein Regal um.

Die jetzt integrierten Umbauten von John Ogness und Thomas Gleixner stellen den zweiten Anlauf dar, die Printk-Schwäche zu beseitigen. Der Erste hat es im Sommer 2022 schon in den Kernel geschafft, nachdem die Entwickler anstatt einiger Monate damals schon über drei Jahre an dem Ganzen gearbeitet hatten. Allerdings traten kurz danach Bugs bei der Synchronisation der Meldungen hervor. Daraufhin kickten die Entwickler das Ganze vor der Fertigstellung von Linux 5.19, um die Sache anders anzugehen – und das hat halt noch einmal zwei weitere Jahre gedauert. Derlei passiert sehr selten, ist aber auch jetzt wieder im Bereich des Möglichen, daher ist ein Zurückrudern vor der Freigabe von 6.12 noch im Bereich des Möglichen.

Realtime-Herzstück schon vor über zwei Jahren integriert

Auf den Printk-Umbau folgten Freitag um 6 Uhr morgens drei vergleichsweise kleine Änderungen mit großen Auswirkungen: Durch sie lässt sich bei der Konfiguration zum Bau eines Kernels für ARM64, RISC-V und x86-64-Systeme (32- und 64-Bit) jetzt die Option CONFIG_PREEMPT_RT aktivieren, die zum Bau eines "Fully Preemptible Kernel (Real-Time)" führt.

Bislang war diese Option nicht auswählbar, obwohl der für sie zuständige Code schon bei Linux 5.15 mit dem Herzstück der Realtime-Patches eingeflossen war. Durch Letzteres handhabt ein mit CONFIG_PREEMPT_RT kompilierter Kernel zentrale Locking-Techniken wie Spinlocks, Mutexes und Rwlocks anders, damit er nahezu alle von ihm erledigten Aufgaben ohne größere Verzögerung unterbrechen kann.

Dadurch kann sich Linux fast jederzeit extrem zügig wichtigem zuwenden: Einem oder mehreren, mit Echtzeit-Prioritäten gekennzeichneten Programmen, die ihre Aufgabe immer und unbedingt in einer vorher definierten Zeitspanne erledigen müssen. Also auch, wenn ein unbedeutender Wartungsprozess das System gerade immens fordert und so sehr widrige Umstände schafft – etwa ein Dateisystemcheck, ein Update-Tool oder eine Log-Analyse-Software. Welche Programme der Kernel wie stark bevorzugen soll, legt die Realtime-Priorisierung des Prozesses fest. Auf Wunsch lässt sich die Zeitzuteilung mit dem 2014 in Kernel 3.14 eingeflossenen und speziell für Echtzeit-Anforderungen gemachten Deadline-Scheduler noch gezielter steuern.

Echtzeit-Support bei Distributionen meist eine Extrawurst

Durch den Echtzeit-Support im offiziellen Kernel dürften fortan mehr Distributoren gewillt sein, neben dem Standard-Kernel auch einen Realtime-tauglichen Kernel auszuliefern. Separate Kernel-Images samt passender Module sind derzeit üblich, denn die größere Bereitschaft zu Kontextwechseln kann beispielsweise Datenträger- oder Netzwerk-Durchsatz leicht reduzieren – ähnlich wie Menschen manchmal länger für eine Aufgabe brauchen, die diese Tätigkeit für jede parallel eingehenden Mail-, Chat- oder Social-Media-Nachricht kurzzeitig unterbrechen, statt solche gelegentlich gebündelt abzuarbeiten.

Diesen Nachteil versprechen Ansätze wie "Lazy Preemption" ganz oder größtenteils zu vermeiden, wenn keine Echtzeit gefragt ist. Noch ist aber ungewiss, ob die für derlei nötigen Umbauten je so weit reifen, dass sie in den offiziellen Kernel einfließen; wenn sie den Sprung irgendwann schaffen, könnten Mainstream-Distributionen die speziellen und Extraarbeit bereitenden Echtzeit-Kernel-Images wieder aufgeben.

20 Jahre Entwicklungsarbeit

Alle jetzt und die meisten zuvor eingeflossenen Änderungen zum Realtime-Support haben die PREEMPT_RT-Entwickler im RT-Tree vorangetrieben und zur Integrationsreife gebracht; zugleich haben sie darüber auch für Interessierte nutzbare Versionen erstellt und jahrelang gepflegt. Mit diesem Kernel-Zweig und dem kurz danach entstandenen PREEMPT_RT-Patch hatte die Entwicklung der Realtime-Support für den offiziellen Linux-Kernel kurz nach dem Herbstanfang 2004 richtig begonnen.

Angesichts des zwanzigsten Jubiläums der Bemühungen fand Donnerstag eine kleine Party im Umfeld der derzeit in Wien abgehaltenen Linux Plumbers Conference (LPC) statt. Nachdem die Printk-Änderungen vor wenigen Tagen eingeflossen waren, übergab Thomas Gleixner die Bitte zur Aufnahme der drei oben erwähnten Änderungen für den PREEMPT_RT-Support persönlich und in ausgedruckter Form an Torvalds und verbeugte sich dabei für die Hilfe; normalerweise erhält der Linux-Erfinder und Hauptentwickler solche per Mail ohne derlei Brimborium.

Gleixner von der deutschen Firma Linutronix ist die Haupttriebkraft hinter dem Realtime-Support für den Standard-Kernel. Er und seine vielen Helfer können sich jetzt aber keineswegs einfach zur Ruhe setzen, denn es gibt noch einiges an Feinschliff zu erledigen. So schaffen es wahrscheinlich einige Änderungen nicht mehr in Kernel 6.12, damit der Treiber für serielle Schnittstellen beim Logging über serielle Konsolen nicht zu lange in nicht unterbrechbaren Code verweilt.

Ohnehin müssen die Entwickler des RT-Tree in Zukunft stetig darauf achten, dass unbedarfte Änderungen irgendeines Kernel-Entwicklers nicht ungewollt lange Latenzen auslösen: So ein Fauxpas in kritischen Codepfaden kann schnell passieren. Und einer reicht, um die Echtzeiteignung von Linux zu ruinieren.

RT-Support für weitere Prozessorarchitekturen

Unterstützung für die PowerPC-Architektur und 32-Bit-ARM-Systeme steht auch noch zur Diskussion, benötigt aber noch kleinere Anpassungen. Außerdem gibt es noch einige Kernel-Teile, die bekanntermaßen querschießen können; darunter etwa der Support für die transparente Verwendung großer Speicherseiten (Transparent Huge Pages) oder der für viele Grafikkerne von Intel zuständige Grafiktreiber i915. Einige Hintergründe dazu liefert ein LWN.net-Artikel aus dem Jahr 2023 zu einer Fragestunde mit Gleixner. Wahrscheinlich lauern in Treibern noch zahlreiche weitere unentdeckte Probleme – insbesondere, wenn bislang niemand diese im Echtzeitbetrieb im Einsatz hatte.

Ohnehin ist harte Echtzeit nichts, was man einfach per Handschlag aktiviert – vielmehr müssen Nutzer ihre Hard- und Software sowie den Kernel oft individuell optimieren und testen, damit ein Realtime-taugliches Betriebssystem die für gängige Echtzeit-Einsatzgebiete gewünschten Antwortzeiten in der Praxis auch tatsächlich erreicht.

Einen groben Eindruck der Fallstricke hat John Ogness vor einiger Zeit in einem Blog-Beitrag zusammengefasst. Stromspartechniken schießen etwa gerne quer und wollen daher vielfach deaktiviert werden. Manche Hardware ist laut Ogness zudem komplett ungeeignet. Schuld daran können etwa System Management Interrupts (SMIs) sein, bei denen die Mainboard-Firmware kurzweilig Linux die Kontrolle entzieht, um sich um die Emulation veralteter Techniken, Lüftersteuerung, Management Engine und ähnliche Dinge zu kümmern – was schnell zu ungewollt großen Latenzen führt, bei denen das Betriebssystem nur machtlos zuschauen kann.

Allgemeine Optimierungen durch die RT-Entwickler

Für die meisten Notebooks, Desktops und Server sind die neuen Echtzeitfähigkeiten des Kernels daher letztlich nicht sonderlich von Belang. Trotzdem haben praktisch alle Linux-Nutzer den Entwicklern des RT-Trees viel zu verdanken: Von ihnen stammen Tausende von Umbauten, die den Kernel in den letzten zwei Jahrzehnten in zahlreichen Bereichen erheblich verbessert haben. So haben die Realtime-Entwickler beispielsweise viele Skalierungsprobleme bemerkt und beseitigt, lange bevor diese auf Allerwelts-Hardware zum Problem wurden – was einer der Hauptgründe ist, warum Linux schon beim Aufkommen von Vielkernprozessoren gut darin war, das Potenzial damit gebauter Systeme auszuschöpfen.

Die nun endlich gelungene Aufnahme in den Hauptentwicklungszweig von Linux dürfte neue Interessenten anlocken. Mit etwas Glück werden sich einige davon auch bei Pflege und Weiterentwicklung engagieren. Diese stand in den vergangenen zwei Jahrzehnten mehrere Male auf sehr wackeligen Füßen; zeitweise stand sie sogar still, weil sich viele den RT-Tree nutzende Firmen gar nicht oder nur minimal eingebracht haben. Das ist neben der Komplexität des Ganzen ein Hauptgrund, warum die Entwicklung bis zum jetzigen Stand fast zwei Jahrzehnte gedauert hat. An dieser Stelle daher: Einen Glückwunsch an alle beteiligten Entwickler und zugleich vielen Dank für das Engagement!

(dmk)