Echtzeit unter Linux Linux ist ein RTOS!

Seit Kernel-Version 6.12 ist Linux erstmals nativ echtzeitfähig – ohne Patches, ohne Sonderwege. PREEMPT_RT ist nun Teil des Mainline-Kernels und macht Linux endgültig zum vollwertigen RTOS.

Am 29. September 2024 veröffentlichte Linus Torvalds Version 6.12-rc1 des Linux Kernels, die wie üblich viele Neuentwicklungen und nützliche Funktionen enthielt. Auf den ersten Blick mag dies den Anschein eines ganz normalen Linux Releases erweckt haben. Doch insbesondere für industrielle Anwender markierte Kernel 6.12 einen wichtigen Meilenstein einer mehr als 20 Jahre andauernden Entwicklung: Die Echtzeitkonfiguration PREEMPT_RT wurde in den Mainline-Kernel aufgenommen und ermöglicht nun Echtzeit-Scheduling für x86, ARM64 und RISC-V auf dem unveränderten Linux Kernel – Linux wurde zum RTOS!

Die Geschichte von Linux und Echtzeit

Die ersten Lösungen für Linux und Echtzeit entstanden bereits zu Beginn der 2000er Jahre mit Projekten wie RTAI und Xenomai. Insbesondere Xenomai wird bis heute eingesetzt und gepflegt. Die Echtzeitfähigkeit wird durch den Einsatz von zwei Kerneln erreicht: Einem echtzeitfähigen Mikrokernel, der die kritischen Aufgaben übernimmt, und Linux. Linux erhält nur dann Rechenzeit, wenn der Mikrokernel die echtzeitkritischen Aufgaben erledigt hat. Man spricht bei diesem Design von einem „dual-kernel approach“. Abbildung 1 zeigt die Funktionsweise dieses Konzeptes. Auf den ersten Blick erscheint diese Vorgehensweise sehr naheliegend. Der Nachteil solcher Ansätze ist allerdings, dass es keine Aussicht auf Integration der notwendigen Änderungen in den Mainline Linux Kernel gibt. Daher müssen die Anpassungen, wie zum Beispiel der „hardware abstraction layer“, mit relativ großem Aufwand jeweils in neue Kernel-Versionen eingepflegt werden. Außerdem verwenden diese Ansätze eine spezielle API, bestehende Treiber können also nicht übernommen werden.

Bildergalerie

Bildergalerie mit 5 Bildern

Der Gedanke, bestehende Treiber und Infrastruktur wiederverwenden zu können, führte 2004 zur Entwicklung des Realtime Preemption Patch (PREEMPT_RT), welcher Linux nun selbst echtzeifähig machte. Man spricht hierbei von einem „single-kernel approach“. Abbildung 2 verschanschaulicht dieses Konzept.

Zur Treiber- und Applikationsentwicklung sind keine spezielle API und keine speziellen Werkzeuge erforderlich. Um dies zu ermöglichen, waren natürlich ebenfalls Änderungen am Mainline-Kernel notwendig, die für neue Versionen angepasst und gepflegt werden mussten. Schnell hat sich dieser Ansatz als de-facto Standard für Linux und Echtzeit durchgesetzt und die Linuxgemeinde hat sich bereits 2005, in einem sehr frühen Entwicklungsstadium, dafür ausgesprochen PREEMPT_RT in den Hauptentwicklungszweig von Linux zu übernehmen. Mit der Kernel Version 6.12, also nach rund zwanzig Jahren Entwicklungsarbeit, ist dies mittlerweile geschehen. Selbstverständlich wurden in diesem Zeitraum, neben der Bereitstellung und Pflege der Patches für die Echtzeitfähigkeit, kontinuierlich Änderungen in den Linux Kernel eingebracht. Dies umfasste sowohl die Überarbeitung aller Teilbereiche hinsichtlich Unterbrechbarkeit als auch die Integration neuer Subsysteme. In diesem Prozess wurden viele Fehler behoben und Funktionen hinzugefügt, was als Nebeneffekt dazu führte, dass Linux für alle besser wurde. Rückblickend auf diese Geschichte ist der Linux Kernel heute viel leistungsfähiger, als er ohne die Entwicklung für Echtzeitfähigkeit wäre. Um nur einige der Funktionen zu nennen, die im Rahmen dieser Arbeiten entstanden sind: Tracing-Infrastruktur, hochauflösende Timer und Threaded IRQs.

Wie konnte Linux echtzeitfähig werden?

Die Threaded IRQs sind ein gutes Beispiel einer Funktionalität, die für die Echtzeitfähigkeit von Linux benötigt wurde, für alle anderen Nutzer aber ebenfalls einen Vorteil bietet. Ursprünglich wurde dieses Konzept zur Maximierung der Unterbrechbarkeit im Betriebssystem entwickelt.

Bei der Verwendung von Threaded IRQs wird im Interruptkontext lediglich die Interruptquelle geprüft und im Anschluss der entsprechende Handler in Form eines Kernel-Threads aufgeweckt. Dies reduziert die Ausführung von Programmcode, der nicht unterbrochen werden kann, auf ein Minimum. Weiterhin sind Kernel-Threads, wie jeder andere Prozess im System, priorisierbar. Die Bearbeitung unkritischer Interrupts kann also von zeitkritischen Applikationen unterbrochen werden. Abbildung 3 veranschaulicht das Konzept der Threaded IRQs. Neben der erhöhten Unterbrechbarkeit im Betriebssystem bieten die Threaded IRQs auch Vorteile für Anwendungen ohne Echtzeitanforderungen. Bei der Kommunikation mit sehr langsamer Peripherie kann mit dieser Art der Interruptverarbeitung ein merklicher Performancegewinn im Gesamtsystem erreicht werden. Darüber hinaus lässt sich die Bearbeitung von Interrupts, die in einem Kernel-Thread bearbeitet werden, im Fehlerfall wesentlich einfacher untersuchen. Verfügbar sind the Threaded IRQs sowohl mit, als auch ohne Echtzeitkonfiguration des Linux Kernels. Es ändert sich lediglich der Default. Während auf einem echtzeitfähigen System alle Interrupts (mit Ausnahme des Timer Interrupts) in einem Kernel-Thread abgearbeitet werden, so muss dies auf einem System ohne aktivierte Echtzeitfunktionen explizit angefordert werden.

Neben diesem neuen Konzept zur Verarbeitung von Interrupts war ein weiterer zentraler Bestandteil auf dem Weg, Linux echtzeitfähig zu machen, die Überarbeitung der Locking Primitiven. Hierbei wurden Spinlocks durch RT-Mutexe ersetzt. Raw-Spinlocks ersetzen die Eigenschaften der ursprünglichen Spinlocks. Aufgrund dieser Anpassungen wurden die Änderungen von PREEMPT_RT auch lange als „Sleeping Spinlocks Patch“ bezeichnet. Diese Arbeiten wurden 2021 mit der Version 5.15 in den Linux Kernel übernommen.

Nach der Aufnahme der überarbeiteten Locking Primitiven war ein letzter verbleibender Punkt, der die Integration von PREEMPT_RT nach Mainline-Linux verzögerte, die Neuimplementierung der sogenannten printk() Funktion. Diese dient im Betriebssystem zur Ausgabe von Meldungen in einen Ringbuffer, welcher vom Anwender ausgelesen werden kann. Üblicherweise ist die Ausgabe solcher Kernelmeldungen mit einer Konsole verknüpft, auf Embedded-Systemen ist dies häufig eine serielle Schnittstelle. Der Anwendungsbereich solcher Ausgaben ist sehr breit gefächert. So können ausgegebene Meldungen einfache Informationen enthalten, z.B. ob ein bestimmtes Gerät erkannt wurde. Weiterhin werden auf diesem Wege auch kritische Meldungen bis hin zu Information zu einem Systemabsturz verarbeitet. Nun scheint die Ausgabe von Meldungen in einen Ringbuffer und im Anschluss auf eine Konsole auf den ersten Blick keine komplexe Aufgabe zu sein. Tatsächlich handelt es sich aber um einen der komplexesten Bereiche im Linux-Kernel, da solche Meldungen in jedem Kontext und zu jedem Zeitpunkt ausgegeben werden können. Weiterhin kann die Ausgabe von Meldungen über bestimmte Schnittstellen sehr langsam sein und das zeitliche Verhalten stark beeinflussen. Um dies zu umgehen erfolgt die Konsolenausgabe von printk() Meldungen auf Systemen mit aktivierter Echtzeitkonfiguration asynchron in einem dedizierten Thread. Somit ist die Verwendung von printk() in kritischen Bereichen auch auf Systemen mit Echtzeitanforderungen möglich, ohne das Zeitverhalten zu beeinträchtigen. Dies kann allerdings mit dem Nachteil verbunden sein, dass im Falle eines Systemabsturzes nicht mehr alle Meldungen rechtzeitig ausgegeben werden. Für solch kritische Fälle steht ein Mechanismus zur Verfügung, in denen Meldungen synchron, also direkt aus dem Kontext des Aufrufenden ausgegeben werden können. Hierzu muss der verwendete Konsolentreiber mit speziellen Callbacks die sogenannte NBCON Funktionalität implementieren. Im September 2024 konnten auch diese Änderungen erfolgreich in den Hauptentwicklungszweig von Linux integriert werden, womit der Bereitstellung der PREEMPT_RT Konfiguration in Kernel 6.12 nichts mehr im Wege stand.

Evaluierung der Echtzeiteigenschaften

Neben den Echtzeitfunktionen im Betriebssystem stehen auch verschiedene etablierte Methoden zur Evaluierung des Echtzeitverhaltens zur Verfügung. Das bekannteste Werkzeug für diesen Zweck ist das Programm „cyclictest“. Mit „cyclictest“ lässt sich eine beliebige Anzahl zyklischer Tasks erstellen, die über einen hochauflösenden Timer in einem vom Anwender festgelegten Intervall aufgeweckt werden.

Jeder Thread überprüft nach dem Aufwachen die aktuelle Zeit und vergleicht diese mit der gewünschten Zeit. Die mit diesem Verfahren ermittelten Latenzen werden kontinuierlich an einen Überwachungsthread gemeldet. Abbildung 4 veranschaulicht dieses Verfahren. Neben den aktuell ermittelten Daten und der Anzeige der maximalen Latenz können mit cyclictest auch Histogramme erzeugt werden. In der QA-Farm (https://www.osadl.org/QA) der Open Source Automation Development Lab (OSADL) eG werden mit „cyclictest“ unter definierten Lastszenarien kontinuierlich Messungen auf unterschiedlichster Hardware und mit verschiedenen Versionen des Linux Kernels ermittelt. Dies dient der Qualitätssicherung und der Bereitstellung von Langzeitdaten. Weiterhin stellt OSADL Patches zur Verfügung, die die Suche nach der Ursache hoher Systemlatenzen erleichtern (https://www.osadl.org/Add-on).

Mit dem „timerlat Tracer“ und dem darauf aufbauenden RTLA Framework (welches im tools/ Verzeichnis des Linux-Kernels zur Verfügung steht) bietet Linux mittlerweile auch eine eingebaute Methode, um die Timerlatenzen zu messen.

Abbildung 5 zeigt den Aufruf des Programmes „rtla timerlat top“. Hierbei werden pro CPU verschiedene Kernel und User-Threads in einem definierten Intervall gestartet. Die ermittelte Latenz wird kontinuierlich dargestellt. Mit der sogenannten autotrace Funktion kann die mögliche Ursache unerwünscht hoher Latenzen ermittelt werden.

Weiterentwicklung und Pflege

Mit der Aufnahme der PREEMPT_RT-Konfiguration in den Mainline-Kernel wurde ein bedeutender Meilenstein erreicht: Linux kann nun ohne zusätzliche Änderungen als Echtzeitbetriebssystem eingesetzt werden! Doch dieser Meilenstein markiert bei weitem nicht das Ende der Arbeiten an PREEMPT_RT. Wie jeder Teilbereich in Linux muss auch PREEMPT_RT kontinuierlich gewartet und gepflegt werden. Somit besteht die Notwendigkeit dauerhaft eine Finanzierung dieser Arbeiten sicherzustellen. Dies ist umso kritischer, wenn man betrachtet, dass es sich nicht um ein isoliertes Subsystem, sondern um eine Kernfunktionalität des Linux Kernels handelt, die alle Teilbereiche tangiert. Zudem gibt es noch viele Verbesserungen und fehlende Funktionalitäten, die noch implementiert und integriert werden müssen. So wird im Mainline-Kernel PREEMPT_RT für die in der Industrie noch sehr verbreitete 32-bit ARM Architektur noch nicht unterstützt. Auch die Verwendung von PREEMPT_RT in Kombination mit beschleunigter Grafik erfordert noch einige wesentliche Anpassungen. Die Wartung von PREEMPT_RT und die Implementierung fehlender Funktionen werden über das „ Real-Time Linux (RT Linux)“ Projekt der Linux Foundation finanziert und koordiniert. Alle im Rahmen des Projektes entwickelten Änderungen stehen nach wie vor als Patchset zur Verfügung, bevor diese in den Hauptentwicklungszweig integriert wurden. Weitere Informationen zur Verwendung von Linux als Echtzeitbetriebssystem und zu Möglichkeiten, die Finanzierung der Wartung und Weiterentwicklung von PREEMPT_RT zu unterstützen, finden sich auf der Projektseite unter: https://realtime-linux.org  (sg)

Dieser Beitrag stammt von unserem Schwesterportal Embedded Software Engineering.

(ID:50611771)