Linux Kernel: Linus Torvalds akzeptiert Extensible Scheduler
Mit Linux 6.11 soll der neue Scheduler kommen, der Finetuning mit einem Baukastenprinzip erlaubt. Damit dringt eBPF tiefer in Basisfunktionen des Kernels vor.
Der Pinguin ist Vorbild für das Kernel-Logo Tux.
(Bild: Daniel AJ Sokolov)
Am Dienstag kündigte Linus Torvalds an, den Extensible Scheduler (sched_ex) in den Mainline-Kernel aufnehmen zu wollen. Er plant dies für Linux 6.11, also das übernächste Kernel-Release. Aktuell laufen die Arbeiten für den im Juli kommenden Linux-Kernel 6.10.
Der Extensible Scheduler ermöglicht es, Aufgaben des CPU-Schedulers in eBPF-Programme auszulagern. eBPF sind prozessorunabhängige Byte-Code-Programme, die der Kernel "just in time" (JIT) in Maschinencode übersetzt und ausführt. Sie erlauben es, Funktionalität nachträglich und zur Laufzeit in den Kernel aufzunehmen. Ein Nachladen eines Kernel-Moduls oder gar das Ändern des Kernel-Quelltextes entfällt.
Neben interessanten neuen Möglichkeiten ruft dieser flexible Scheduler auch kritische Stimmen auf den Plan.
Mehr Flexibilität
Das CPU-Scheduling verteilt Rechenzeit nach vordefinierten Regeln an die laufenden Prozesse. Je nach Anwendungsbereich erfordert dies ein unterschiedliches Regelwerk. So haben zeitkritische Echtzeitanwendungen andere Anforderungen an das Zuteilen von Prozessorzeit als mehr oder weniger gleichberechtigte Prozesse auf einem Webserver.
Linux hat hierfür bereits mehrere Scheduler im Gepäck. Neben dem Standard-Scheduler hält Linux unter anderem auch Scheduler für Spezialfälle wie Echtzeitbetrieb und für Deadline-Scheduling bereit. Letzterer reserviert flexibel einen Prozentsatz der CPU-Zeit für administrative Prozesse und sorgt dafür, dass auch bei vielen Echtzeitprozessen das Gesamtsystem nicht stockt.
Der Extensible Scheduler erlaubt, das Verhalten beim Verteilen von Rechenzeit nach dem Baukastenprinzip flexibel zu verändern. Die bestehenden Scheduler lassen sich – ohne Eingriff in den Kernel-Quelltext – nur in engen Schranken durch vordefinierte Parameter beeinflussen.
Einsatzmöglichkeiten
Im Wesentlichen ergeben sich für den Extensible Scheduler zwei sinnvolle Anwendungsbereiche. Einerseits nennen die Schöpfer des "Baukasten-Schedulers" das Experimentieren und Erarbeiten neuer Scheduling-Ansätze. Ohne zeitraubende Compile- und Reboot-Zyklen können die Entwickler zur Laufzeit mit dem Scheduling "spielen" und so schneller zu neuen Erkenntnissen gelangen.
Andererseits können von einem Baukasten-Scheduler Nischenszenarien profitieren. Google experimentiert in seinem ghOSt-Framework bereits mit Optimierungen via Userspace-Scheduling. Auch in ChromeOS existiert bereits ein Prototyp auf sched_ex-Basis zum Reduzieren von Latenzen. Meta verwendet den sched_ex in einer großen Produktivumgebung im Benchmarking für Werbung. Das sind alles Spezialfälle, die in einem "Scheduler von der Stange" keine Berücksichtigung finden würden. Der Kernel legt zwar immer wieder beim Optimieren seiner Scheduler nach. So tauschte das Kernel-Team nach 15 Jahren in Linux 6.6 den Standard-Scheduler gegen einen zeitgemäßeren Ansatz aus. Sehr spezielle Anforderungen in kleinen Einsatznischen werden die fest verdrahteten Scheduler im Kernel jedoch niemals hinreichend unterstützen können. Gerade hier sehen die Entwickler des Extensible Schedulers einen weiteren Einsatzbereich.
Kritische Blicke
Die Baukastenidee beim Scheduler ist nicht neu. Bereits 2004 gab es einen Ansatz, Scheduler im "Stecksystem" flexibel zusammensetzen zu können. Dieser erfuhr eine klare Abfuhr mit dem Argument, es sei besser, die Kräfte für das Tuning des Standard-Schedulers zu bündeln.
Neben den unterschiedlichen Einsatzgebieten sind Scheduler heute mit verschiedenen Herausforderungen konfrontiert. Zu nennen wären hybride Architekturen mit unterschiedlich leistungsfähigen oder spezialisierten Prozessoren und Kernen. Jedoch auch das Power-Management stellt Scheduler auf die Probe, sollen die Systeme doch möglichst wenig Energie verschwenden – wohl mit ein Grund, warum Linus Torvalds dem Extensible Scheduler jetzt eine Chance im Mainline-Kernel geben will.
Einige Kernel-Entwickler sehen das kritisch. eBPF dringt immer tiefer in den Kernel ein. Seit Linux 6.3 können die Erweiterungen aus dem Userspace auf wesentliche Kernel-interne Strukturen zugreifen. Mit dem Extensible Scheduler greift eBPF nach einer Kernaufgabe des Betriebssystems. Befürchtungen gegen eBPF steigen, die Stabilität und Sicherheit des Systems zu gefährden. Schließlich kommen die eBPF-Programme aus dem Userspace und damit von außerhalb des Kernels. Die Kontrolle seitens des Kernel-Teams ist damit nicht mehr möglich.
Zusammenarbeit als Strategie
Auch das alte Argument kommt wieder auf den Plan: Der Extensible Scheduler könne zum Verzetteln von Entwicklerressourcen führen. Die Ressourcen gehören gebündelt für die bestehenden Scheduler.
Torvalds sieht diese Gefahr nicht. Zudem glaube er sinngemäß allgemein nicht daran, dass generell außerhalb des Kernels gepflegter Code eine bessere Strategie zum Umgang mit kontroversen Ansätzen darstellt. Es sei besser, den Extensible Scheduler in den Kernel aufzunehmen und gemeinsam daran zu arbeiten. Im Zuge dieser Zusammenarbeit könnten dann etwaige Bedenken angebracht und Zweifel ausgeräumt werden.
(ktn)
