Linux-Kernel 6.8.1: Korrekturen für Kernel 6.8

Inhaltsverzeichnis

Linus Torvalds Release-Meldung gab für Linux 6.8 keine großen Änderungen bekannt. Wer auf neue Dateisysteme, weltverändernde Features und Unmengen neuer unterstützter Hardware wartete, wird tatsächlich enttäuscht. Lediglich der neue Grafiktreiber für Intel Xe sticht für Torvalds in diesem Sinne als Novum hervor. Dennoch hat Linux 6.8 einiges an interessantem im Gepäck, wenngleich sich das meiste unter der Oberfläche verbirgt.

Zudem ist bereits Linux 6.8.1 erschienen. Das Update auf 6.8.1 wird allen Benutzern von Linux 6.8 dringend empfohlen. Es enthält wichtige Sicherheits- und Bugfixes.

Erster Treiber in Rust

Bislang war mit Rust im stabilen Linux-Kernel relativ wenig anzufangen. Ende 2022 feierte Rust zwar offiziell mit Kernel 6.1 seinen Einstand. Nutzen konnte man das aber bislang für neue Module beziehungsweise Treiber nicht. Mit Linux 6.8 kommt nun der erste nutzbare, funktionsfähige und in Rust programmierte Treiber. Dieser Treiber unterstützt Fast-Ethernet-Controller von Asix Electronics vom Typ AX88796B. Die Hardware kommt hauptsächlich im Embedded-Bereich in industriellen Anwendungen zum Einsatz.

Linux hat bereits einen in C geschriebenen Treiber für AX88796B im Gepäck. Die Rust-Variante reimplementiert die Funktion des C-Pendants eins zu eins. Standardmäßig ist die C-Variante im Linux-Kernel vorausgewählt. Will man die Rust-Version, ist diese beim Konfigurieren des Kernels vor dem Build entsprechend über den Schalter AX88796B_RUST_PHY auszuwählen.

Es ist ein geschickter Schachzug, einen bereits existierenden und funktionierenden Treiber in Rust nachzubauen. Da der gleiche Treiber einmal in C und einmal in Rust vorliegt, lässt sich Rust direkt mit C im Praxistest vergleichen und sinnvoll testen. Bei einem neuen Treiber für eine bislang nicht unterstützte Hardware wäre das nicht möglich.

Zeitgleich schafft das Entwicklerteam den notwendigen Unterbau für physische Netzwerktreiber in Form der notwendigen Abstraktionsschichten. Zukünftige Netzwerktreiber lassen sich damit grundsätzlich wahlweise in C oder Rust programmieren.

Arbeitsteilung

Im Fokus bleibt bei Linux-Kernel das Scheduling, also das Verteilen von Rechenzeit auf die einzelnen konkurrierenden Prozesse. Nachdem bereits Linux 6.6 radikal den Standard-Scheduler ausgetauscht hatte, legt Linux 6.8 in diesem Bereich noch mal nach.

Der mit Linux 6.6 eingeführte neue Scheduler EEVDF (Earliest Eligible Virtual Deadline First) erfährt ein Tuning. Mit dem Einführen eines Fastpath-Mechanismus lässt sich der zum Zuge kommenden Task effizienter auswählen. Das Ganze auch noch mit konstanter Größenordnung von O(1). Erste Tests zeigen, dass der "O(1) Fastpath" tatsächlich die Task-Selection und damit den Scheduler als solchen effizienter arbeiten lässt.

Im Echtzeit-Bereich optimiert der neue Kernel den Deadline-Scheduler. Dieser basiert auf dem recht einfachen Konzept der "POSIX Realtime Scheduling Classes". Die Echtzeit-Tasks geben an, wie viel Rechenzeit sie benötigen und bis wann sie ihre Arbeiten abgeschlossen haben müssen. Je nachdem, wie dringend solche Tasks abgeschlossen sein müssen, werden sie priorisiert und erhalten früher CPU-Zeit. Würde ein solches System ohne irgendwelche weitere Vorkehrungen laufen, könnte es passieren, dass die Echtzeit-Tasks die "normalen" verhungern lassen. Alles, was nicht den "Echtzeitstempel" hat, müsste hinten anstehen. Ein ausgelastetes System würde in dem Fall schnell als "hängend" wahrgenommen. Wohingegen die Echtzeitaufgaben abgearbeitet würden, könnten alle Kontrollmöglichkeiten wie Login, administrative Aufgaben starten etc. auf Dauer ausgebremst werden. Eine Einflussnahme auf das System wäre nicht mehr möglich. Ein Kaltstart wäre die einzige Lösung.

Terminsache

Um dem vorzubeugen, reserviert der Kernel einen festen Anteil an CPU-Zeit für diese niedrig priorisierten Tasks. Per Voreinstellung sind das fünf Prozent; 95 Prozent bleiben für die Echtzeitverarbeitung. Ein System hat damit unabhängig von der Auslastung immer genügend Ressourcen zum Administrieren. Die Lösung nennt sich "Realtime Throttling", also "Echtzeitdrosselung".

Diese Lösung ist allerdings alles andere als optimal. Diese reservierten fünf Prozent bleiben auch dann reserviert, wenn gar keine niedrig priosisierten Tasks auszuführen sind. Das System ist damit konstant fünf Prozent "idle", selbst wenn die Echtzeitprozesse dieses Quäntchen mehr an Leistung gut brauchen könnten.

Die neue Lösung präsentiert sich als "Deadline-Server". Statt fix CPU-Zeit zu reservieren, verfrachtet der Scheduler die niedrig priorisierten Tasks in eine separate Deadline-Klasse – den "Deadline-Server". Sie ist höher priorisiert als die POSIX-Realtime-Klassen, in der sich die Echtzeitprozsse tummeln. Damit nehmen die an sich "niedrig" priorisierten Tasks "höchst" bevorzugt am Echtzeitreigen teil und werden den Echtzeit-Tasks immer vorgezogen.

Der Clou offenbart sich erst auf den zweiten Blick. Der "Deadline-Server" deklariert für sich einen CPU-Bedarf von fünf Prozent. Damit ist er zunächst auch gedeckelt, sodass die Echtzeit-Tasks wie ursprünglich mindestens 95 Prozent der CPU-Zeit erhalten. Sollten im "Deadline-Server" gar keine Tasks zum Ausführen anstehen, erkennt das der Scheduler und verteilt die angeforderten, aber nicht beanspruchten fünf Prozent CPU-Zeit kurzerhand an die Echtzeit-Tasks. Somit ist einerseits sichergestellt, dass die "niedrig" priorisierten, aber administrativ wichtigen Tasks immer ausreichend CPU-Zeit erhalten. Andererseits liegen diese reservierten CPU-Ressourcen nicht einfach brach, wenn sie nicht benötigt werden.