Linux 6.12: Scheduler jetzt erweiterbar und EEVDF-Umbau komplett

Nach heftigen Kontroversen hat es der "extensible Scheduler" nun in den offiziellen Kernel geschafft. Neu ist auch der Deadline Server für Echtzeit-Umgebungen.

In Pocket speichern vorlesen Druckansicht 9 Kommentare lesen
Pinguin sitzt vor einem Computer, der einen Pinguin und die Schrift "Linux" anzeigt

(Bild: Bild erstellt mit KI in Bing Designer durch heise online / dmk)

Lesezeit: 7 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Das am 18. oder 25. November erwartete Linux 6.12 bringt gleich drei größere Änderungen am Code, der kontrolliert, wann und wie lange Prozesse den Prozessor nutzen. Die am heißesten erwartete ist die als "Sched_Ext" bekannte "Extensible Scheduler Class", durch die der Prozess-Scheduler viele Entscheidungen beim Verteilen der Prozessorzeit an BPF-Programme delegieren kann. Kundige können solche selbst schreiben und in den Kernel laden, um die Zeitverteilung so an ihre Bedürfnisse anzupassen, ohne Quellcode von Linux verändern zu müssen.

Die Kernel-Entwickler haben ferner den bei Linux 6.6 begonnen Umbau des Zeitverteilungs-Algorithmus abgeschlossen, durch den der Prozess-Scheduler das Verfahren "Earliest Eligible Virtual Deadline First" (EEVDF) verwendet. Dieses Feintuning ermöglicht, die Latenz von zumeist kurz laufenden Anwendungen zu reduzieren.

Die dritte Neuerung ist die "SCHED_DEADLINE Server Infrastructure": Bei Systemen mit Echtzeitprozessen soll sie besser sicherstellen, dass niedrige priorisierte Anwendungen nach wie vor ausreichend zum Zuge kommen. Diese Funktion ist die letzte größere Änderung eines zentralen und angesehenen Entwicklers, der im Juni mit 37 Jahren verstorben ist.

Die Extensible Scheduler Class haben maßgeblich Entwickler von Meta vorangetrieben: Das Unternehmen setzt Sched_Ext selbst bereits ein, um die Zuteilung von Prozessorzeit besser an die Bedürfnisse in ihren riesigen Rechenzentren anpassen zu können. Dazu schreiben Entwickler BPF-Programme für die Workloads der verschiedenen Server-Klassen; diese werden dann zur Laufzeit in den Kernel geladen, der sie mit der BPF-Virtual-Machine im Kernel-Kontext ausführt. Solche BPF-Programme laufen weniger abgeschirmt als reguläre Anwendungsprogramme, unterliegen aber einigen Sicherheitsbeschränkungen – letztlich können sie aber deutlich schneller mit dem Kernel interagieren und direkt auf von ihm verarbeitete Daten zugreifen. BPF-Programme kommen im Linux-Umfeld bereits vielfältig zum Einsatz, etwa bei Sicherheitsmechanismen von Systemd, zur Performance-Analyse oder zur performanten Steuerung von Netzwerk-Datenströmen.

Einige Entwickler und Unternehmen arbeiten derweil bereits an Sched_Ext-Programmen, um die Zuteilung von Prozessorzeit für größere Nutzergruppen zu optimieren – etwa für Gamer, um Ruckler bei ressourcenfordernden Spielen zu vermeiden. Es steht zu erwarten, dass einige Distributionen solche BPF-Programme in Zukunft gleich mitbringen und beim Start von Spielen vorübergehend aktivieren. Den Quellcode müssen sie dabei offenlegen, denn Sched_Ext-Programmen müssen wie der Kernel-Code der GPLv2 oder einer kompatiblen Lizenz unterliegen.

Wahrscheinlich werden bald allerlei solche Sched_Ext-Programme zirkulieren. Wie bei derlei Schnittstellen für Erweiterungen üblich, dürften einige davon Probleme und Funktionslücken des Prozess-Schedulers umschiffen, die womöglich besser im C-Code des Schedulers beseitigt wären. Im dümmsten Fall können dadurch Probleme für Anwender entstehen – etwa wenn diese eine Sched_Ext-Erweiterung fürs Gaming nutzen wollen, die vielleicht gar nicht oder nur schlecht mit einer anderen harmoniert, die die Leistung von Prozessoren mit unterschiedlich schnellen CPU-Kernen optimiert.

Wegen solcher und zahlreicher anderen Aspekte haben sich mehrere Entwickler des Prozessor-Schedulers von Linux gegen die Aufnahme von Sched_Ext ausgesprochen – oftmals sehr deutlich. Die andere Seite hat zugleich unter anderem argumentiert, Sched_Ext ermöglicht ein leichteres Experimentieren mit neuen Scheduler-Verfahren und könnte so vielleicht die Weiterentwicklung des regulären Schedulers fördern. Linus Torvalds' Einstellung war eine Weile ungewiss. Er war viele Jahre ein Verfechter des Ansatzes "der Kernel sollte nur einen Prozess-Scheduler haben, der alle Einsatzgebiete abdeckt" – daher blieben etwa der alternative "Brain Fuck Scheduler" (BFS) von Entwicklern wie Con Kolivas und andere Scheduler jahrelang außen vor, obwohl die sich in gewissen Kreisen extrem großer Beliebtheit erfreuen.

Torvalds hat sich dann aber vor rund einem Jahr beim jährlichen Kernel Maintainer Summit deutlich für die Aufnahme von Sched_Ext ausgesprochen. Zu der kam es dann aber erst einmal nicht. Vor einigen Monaten hat er dann durchblicken lassen, die Entwickler des regulären Prozess-Schedulers zu übergehen und Sched_Ext trotz ihrer Kritik in Linux 6.11 zu integrieren, wenn keine Einigung in Sicht käme. Daraufhin haben beide Seiten abermals an einigen Details geschraubt, damit sich alle zumindest etwas besser mit dem Ganzen arrangieren können; dadurch wurde es statt 6.11 am Ende dann 6.12.

Einige Hintergründe zur ganzen Kontroverse und zu Sched_Ext im Allgemeinen erläutern die LWN.net-Artikel "The extensible scheduler class" und Another push for sched_ext. Weitere Einblicke liefert das Begleitschreiben zu den Sched_Ext-Patches, die Beschreibung im Merge Commit und die technische Dokumentation zu Sched_Ext.

Zufällig zur gleichen Zeit haben Entwickler des regulären Schedulers den bei Linux 6.6 begonnenen Umbau zur Rechenzeitverteilung mit dem Verfahren "Earliest Eligible Virtual Deadline First" (EEVDF) komplettiert und verfeinert. Unter anderem bringt das Vorteile für Anwendungen, die schnell reagieren sollen, aber zumeist nur kurz laufen.

Solche Prozesse kann der Kernel jetzt häufiger drannehmen – und entreißt dazu gegebenenfalls auch Anwendungen die CPU, selbst wenn diese ihre aktuell genutzte Zeitscheibe noch gar nicht ausgeschöpft haben. Bislang machte der Kernel das nur, wenn er Prozesse mit Echtzeit-Priorität dran nehmen wollte. Der Kernel wählt diesen Weg aber nicht von sich aus, sondern nur für Prozesse, die kürzere Zeitscheiben explizit via sched_setattr() und sched_attr::sched_runtime anfordern. Sie werden so letztlich häufiger ausgeführt, was die Latenz senkt – zugleich aber halt auch kürzer, denn am Ende bekommen sie insgesamt ebenso viel CPU-Zeit wie andere Prozesse mit der gleichen Priorität, um Ungerechtigkeiten zu vermeiden.

Die Dokumentation zu dieser umsetzenden Änderung erläutert das Ganze detaillierter mithilfe cleverer ASCII-Art; weitere Details zu den Umbauten und der Zeitverteilung mit kürzeren Zeitscheiben ("Slices") liefert LWN.net im Text "Completing the EEVDF scheduler". Auch der Merge-Kommentar der größten Änderungen am Scheduler umreißt diese und andere Verbesserungen an EEVDF grob.

In dem Merge-Kommentar findet auch die dritte größere Änderung Erwähnung: die SCHED_DEADLINE Server Infrastructure. Sie ist für Systeme gedacht, die Echtzeit-Anwendungen ausführen und deren Zeitzuteilung mit Hilfe der Deadline Scheduling Class des regulären Schedulers regeln. Bei diesen konnte es bislang vorkommen, dass Echtzeit-Anwendungen den Prozessor weitgehend monopolisieren, sodass Prozesse mit regulären Prioritäten nur noch unzureichend zum Zuge kamen. Eine "Realtime Throttling" genannter Ansatz sollte derlei schon bislang unterbinden, aber das funktionierte vielfach eher dürftig. Die neue Infrastruktur geht anders an die Sache heran und stellt in der Standard-Konfiguration etwa sicher, dass reguläre Prozesse mindestens fünf Prozent der Prozessorzeit erhalten. Weitere Einblicke zum Verfahren liefert der LWN.net-Artikel "Deadline servers as a realtime throttling replacement".

Triebkraft hinter dieser neuen Infrastruktur war Daniel Bristot de Oliveira. Es ist sein letzter signifikanter Beitrag zu Linux, denn er ist im Juni im Alter von 37 Jahren verstorben. Bristot war ein seit Jahren überaus engagierter und angesehener Entwickler im Linux-Realtime-Bereich.

Portraitfoto des verstorbenen Daniel Bristot de Oliveira.

(Bild: bristot.me / Daniel Bristot de Oliveira)

Mehrere Dutzend Entwickler erinnerten vergangene Woche auf einer Konferenz in einer "Celebration of Life" an ihn. Keine zwei Stunden später und wenige Meter weiter erhielt Linus Torvalds dann den Pull Request überreicht, durch den Linux nach 20 Jahren mühevoller Arbeit jetzt von Haus aus Echtzeit-Fähigkeiten mitbringt – eine Errungenschaft, die auch Bristot erheblich zu verdanken ist.

(dmk)