Das Endziel der Echtzeit-Prävention

Der Endpunkt der Linux-Unterstützung für Echtzeit-Preemption

• Die Arbeiten zur Ergänzung von Linux um Echtzeit-Unterstützung begannen 2004 und befinden sich nun in der Schlussphase.
• Ziel der Echtzeit-Preemption ist es, dass Prozesse mit der höchsten Priorität mit minimaler Verzögerung ausgeführt werden können; dafür wird der Kernel in möglichst vielen Situationen präemptierbar gemacht.
• Diese Arbeit führte dazu, dass zentrale Teile des Kernels neu geschrieben wurden, und sie bringt Vorteile, die über Echtzeit-Anwendungsfälle hinausgehen.

Lösung des printk()-Problems

• Die Funktion printk(), die im Kernel verwendet wird, um Nachrichten an die Systemkonsole und ins Log zu senden, arbeitet synchron und kehrt erst zurück, wenn die Nachricht an alle konfigurierten Ziele übertragen wurde.
• Echtzeit-Entwickler verlagerten die printk()-Ausgabe in einen separaten Thread, um sie asynchron zu machen, doch das war nur eine Übergangslösung.
• Seit 2018 wird ernsthaft am printk()-Problem gearbeitet; mit rund 300 Patches nähert sich die Lösung, auch wenn noch einige komplexe Probleme offen sind.

Ausblick auf die Mainline-Integration des Echtzeit-Preemption-Codes

• Es wurde die Hoffnung geäußert, dass der verbleibende Teil des Echtzeit-Preemption-Codes noch vor seinem 20-jährigen Jubiläum Ende 2024 in die Mainline integriert wird.
• Am printk()-Code selbst gab es zuletzt keine Änderungen, aber der Handover-Code wurde so angepasst, dass Konsolentreiber einzeln aktualisiert werden können.
• Der Code wurde so geändert, dass wichtige Nachrichten vollständig in den Nachrichtenpuffer kopiert werden, bevor die erste Zeile ausgegeben wird; außerdem werden Nachrichten zuerst auf einer sicheren Konsole protokolliert, um Systemabstürze durch fehlerhafte Konsolentreiber zu verhindern.

Meinung von GN⁺

• Die Arbeiten zur Ergänzung des Linux-Kernels um Echtzeit-Preemption-Unterstützung sind nahezu abgeschlossen und werden Systemen, die Echtzeitverarbeitung benötigen, große Vorteile bringen.
• Die Asynchronisierung der printk()-Funktion verbessert die Reaktionsfähigkeit des Systems und spielt eine wichtige Rolle beim Erreichen der Ziele der Echtzeit-Preemption.
• Dieser Artikel zeigt einen wichtigen Fortschritt in der Entwicklung des Linux-Kernels und bietet interessante Inhalte für alle, die sich für Kernel-Entwicklung interessieren.

[GN⁺]

Hacker-News-Meinungen

• Vorteile des QNX-Mikrokernels

  • Der QNX-Mikrokernel garantiert seit Jahrzehnten Zuverlässigkeit, indem er für jede Aufgabe feste Obergrenzen setzt.
  • Der Mikrokernel-Code umfasst nur einige zehntausend Zeilen und ist ausschließlich für Speicherzuweisung, CPU-Dispatching und die Nachrichtenübermittlung zwischen Prozessen zuständig.
  • Alle übrigen Funktionen, einschließlich Treibern und Loggern, befinden sich im User Space und können von Threads mit höherer Priorität präemptiert werden.
  • Der QNX-Kernel führt überhaupt keine String-Operationen aus, sodass keine Probleme durch String-Parsing, Formatierung oder Nachrichtenübermittlung entstehen.

• Probleme von Linux bei der Echtzeitverarbeitung

  • Linux ist strukturell nicht für Echtzeitverarbeitung geeignet; der Kernel-Code umfasst Millionen von Zeilen, und der gesamte Code müsste präemptierbar gemacht werden.
  • Aufgrund seiner Untauglichkeit als Echtzeitarchitektur hat die Behebung dieser Probleme Jahrzehnte gedauert.
  • Sich nur auf Kernel-Probleme zu konzentrieren, könnte Probleme auf CPU-Ebene übersehen.

• Die Logging-Funktion des Kernels und reale Anwendungsfälle

  • Es wird erläutert, wie die erheblichen Anstrengungen des Kernels, selbst in Situationen eines Systemabsturzes noch Log-Meldungen auszugeben, in realen Deployments genutzt werden.

• Austauschbarkeit von Echtzeit-Hardware-/Software-Kombinationen

  • Es wird die Frage aufgeworfen, ob Hardware-/Software-Kombinationen, die Echtzeitverarbeitung benötigen, durch günstige, stromsparende ARM- und x86-Chips mit hohem Takt ersetzt werden können.
  • Es wird erwähnt, dass mit steigenden Taktraten die Bedeutung perfekt harter Echtzeitverarbeitung abnehmen könnte.

• Die Unterscheidung zwischen „harten“ und „weichen“ Echtzeitanwendungen

  • Für „harte“ Echtzeitanwendungen ist es ratsam, kein allgemeines Betriebssystem wie Linux zu verwenden.
  • Bei „weichen“ Echtzeitanwendungen (z. B. Videokonferenzen, Audiowiedergabe) sind leichte Verzögerungen oder Frame-Verluste kein großes Problem.
  • Diskussionen darüber, Linux zu einem Echtzeitbetriebssystem zu machen, konzentrieren sich auf „weiche“ Echtzeit-Anwendungsfälle, die bereits möglich sind.
  • Den Kernel vollständig präemptierbar zu machen und die Kontrolle über das Scheduling zu erhöhen, ist weniger ein Versuch, ein Echtzeitbetriebssystem oder Bare-Metal-Code zu ersetzen, als vielmehr ein sinnvoller Schritt zu einer gesunden Systemverwaltung.

• Echtzeitverarbeitung im Linux-Kernel und die Grenzen der Hardware

  • Selbst wenn der Linux-Kernel Echtzeitverarbeitung unterstützt, kann die Hardware aufgrund von Caches und komplexen internen CPU-Funktionen möglicherweise keine Echtzeit garantieren.
  • Für echte Echtzeitverarbeitung werden einfache CPU-Architekturen gegenüber komplexer Hardware bevorzugt.

• Probleme mit synchronem Logging

  • Es wurde erlebt, dass synchrones Logging wie GLOG (Googles Logging-Bibliothek) durch blockierendes Disk-I/O Dienste verzögert.

• Methoden zur Gewährleistung der Reaktionsfähigkeit eines bestimmten Prozesses

  • Wenn die Reaktionsfähigkeit eines bestimmten Prozesses wichtig ist, sollte ihm ein dedizierter CPU-Kern und ein zusammenhängender Speicherbereich zugewiesen werden, und er sollte direkten Zugriff auf eine Netzwerkkarte erhalten, die vom restlichen Betriebssystem getrennt ist.

• Echtzeitpräemption in Linux und frühere Erfahrungen

  • Es werden frühere Erfahrungen geteilt, bei denen der RT_PREEMPT-Patch auf den Linux-Kernel angewendet und in wissenschaftlichen Geräten eingesetzt wurde, sowie der Eindruck von den dadurch verbesserten Latenzen und dem geringeren Jitter.

• Auswirkungen auf normale Nutzer

  • Es wird die Frage gestellt, welche Bedeutung Echtzeitverarbeitungsfunktionen für normale Nutzer haben, ob sie nur in bestimmten Situationen aktiviert werden sollten und ob sie auch die allgemeine Reaktionsfähigkeit des Systems verbessern könnten.