Linux 5.3 freigegeben: Prioritäten deckeln und Trouble für Nvidia
Seite 2: Echtzeitfähigkeiten im Anflug
Linux soll endlich Echtzeitfähigkeiten erhalten
Die bislang extern im "RT-Tree" gepflegten Änderungen, die aus Linux einen Realtime-Kernel machen, sollen bald in den offiziellen Kernel einfließen. Das gilt mit Linux 5.3 als sicher, nachdem Entwickler vor knapp 15 Jahren erste Patches mit diesem Ziel veröffentlicht haben. Damals mussten sie noch Spott von Linus Torvalds ertragen, denn es erschien unstemmbar viel Aufwand, Echtzeitfähigkeiten sauber in Linux einzubauen; daher war immer unklar, ob je alle Realtime-Patches in den offiziellen Kernel umziehen würden.
Die Entwickler ließen sich davon nicht beirren lassen und schufen mit dem RT-Tree schon bald einen Linux-basierten Realtime-Kernel, der Anklang bei Unternehmen fand. Diese setzen ihn etwa bei Robotern oder der Maschinensteuerung ein: Echtzeitfähigkeiten sind dort gefragt, um bestimmte Aufgaben immer in einer vorher festgelegten Zeitspanne auszuführen – also auch, wenn irgendetwas anderes das System gerade immens fordert. Dazu braucht es unter anderem Reaktionszeiten im unteren Millisekundenbereich, die Linux durch die RT-Patches garantierten kann.
Viele Verbesserungen, die für den RT-Tree entstanden, zogen über die Jahre bereits in den offiziellen Kernel um, weil sie Linux auch für andere Einsatzgebiete attraktiver machten. Unter die Änderungen waren immer mal wieder auch größere Umbauten, die Torvalds erst strikt und lautstark abgelehnt hatte, wenig später dann aber doch ohne Murren akzeptierte. Der RT-Tree enthält dadurch heute gar nicht mehr besonders viele Patches, dafür aber einige kontroverse – teilweise, weil sie zentrale und daher kritische Infrastruktur des Linux-Kernels betreffen, bei der die Entwickler besondere Vorsicht walten lassen.
Patch der Realtime-Entwickler hat vorerst nur Signalwirkung
(Bild: c't/Thorsten Leemhuis)
Für Linux 5.3 hat Linus Torvalds eine Änderung in den offiziellen Kernel integriert, die seit den Anfangstagen im RT-Zweigs stecken und ihn quasi definiert: Den kleinen, aber zentralen Patch, der die Konfigurationsoption CONFIG_PREEMPT_RT nachrüstet – also die Einstellmöglichkeit, um beim Kernel-Bau festlegen zu können, ob das resultierende Kernel-Image denn Realtime-Fähigkeiten bieten soll. Diese Option für einen "Fully Preemptible Kernel (Real-Time/RT)" zeigt sich aber vorerst nicht, denn dazu müssen noch weitere Änderungen aus dem RT-Tree folgen. Die Aufnahme richtet sich nämlich vor allem an Kernel-Entwickler, denen die Änderung signalisieren soll: Sperrt euch nicht grundlos gegen die Aufnahme der verbliebenen RT-Patches, denn Linus Torvalds steht dieser Tage voll hinter der Idee, Realtime-Support in den offiziellen Linux-Kernel einzubauen.
Wie schnell das jetzt gelingt, bleibt abzuwarten. Im Herbst 2018 hatten die RT-Entwickler noch verkündet, alle wesentliche Änderungen im Jahr 2019 in den offiziellen Linux-Kernel zu überführen. Mittlerweile wirkt dieses Ziel äußerst ambitioniert. Die Entwickler ließen aber kürzlich durchblicken: Wenn alles gut geht fließen alle wesentlichen Änderungen schon in Linux 5.5 ein, das Ende Januar erscheinen dürfte.
Für Heimnutzer und Server-Admins ist die Echtzeitfähigkeit von Linux indes nur bedingt relevant: Für Realtime-Support ausgelegte Kernel-Images reagieren zwar zackiger, schneiden aber genau wegen der größeren Reaktionsfreude oft schlechter in Durchsatztests ab. Bei Debian, Fedora, Ubuntu & Co. werden sich Realtime-Funktionen daher wohl nur in optionalen Kernel-Images finden, nicht aber in den standardmäßig verwendeten.
Dies war ein schrittweise aktualisierter Artikel
Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen in Linux 5.3 zu beschreiben. Zur jüngst erfolgten Freigabe dieser Kernel-Version haben wir die Abschnitte umsortiert und Abschnitte zu wichtigeren Neuerungen an den Anfang gestellt. Von nun an behält der Text seine jetzige Form. Details zur Versionshistorie des Artikels finden Sie am Artikelende.
Prozesse schneller oder effizienter abarbeiten
Über das "Scheduler Utilization Clamping" (Uclamp) können Admins oder Entwickler jetzt einzelne Programme speziell auszeichnen, um deren Reaktionsfreude zu steigern oder die Leistungsaufnahme im Zaum zu halten. Letztlich kann man über die neue Funktion einen Prozess, der den Hauptprozessor wenig belastet, so kennzeichnen, als würde er die CPU stärker fordern. Dadurch steigt die Chance, dass der Scheduler den Prozess an einen schnellen Prozessorkern schickt In anderen Fällen kann es den Kernel auch dazu bewegen, die Taktfrequenz des zuständigen CPU-Cores zeitnah zu steigern. Der Prozess erledigt die Arbeit dann zackiger, wodurch sich das System schneller und interaktiver anfühlt. Google denkt offenbar darüber nach, die Funktion bei Android einzusetzen.
Weniger wichtige, aber CPU-hungrige Prozesse lassen sich via Uclamp auch so kennzeichnen, als würden sie den Prozessor weniger nutzen, als sie es tatsächlich tun. Dadurch versucht der Kernel die Arbeit dann mit einem Prozessorkern auszuführen, der generell besonders sparsam arbeitet; alternativ kann er sich auch entscheiden, den Prozessor vom schnellsten in einen möglichst effizienten Betriebsmodus zu schalten.
Über normale Prioritäten lässt sich Vergleichbares oft nicht erreichen: Diese wirken sich nur bedingt auf die Wahl von Prozessorkern und deren Betriebszustand aus, denn dabei spielen andere Faktoren eine größere Rolle. Vor allem vom Kernel per Load Tracking erfasste Daten, durch die er weiß, wie lange und stark ein Prozess die CPU typischerweise nutzt. Durch sie führt der Kernel einfache und typischerweise nur kurz laufende Prozesse eher mit langsameren CPU-Kernen aus, obwohl es für das Interaktivitätsgefühl besser wäre, wenn er sie einem schnelleren Kern zuteilen würde.
Einstellbar sind die Clamping-Werte über den Syscall sched_setattr(). Patches, um die Werte auch bei Control Groups (Cgroups) festlegen zu können, sind noch in Arbeit. Weitere Details zum Ganzen liefern die Kommentare einiger Uclamp-Patches (1, 2, 3, 4, 6, 7, 8, 9, 10) sowie der ein Jahr alte LWN.net-Artikel "Scheduler utilization clamping".
Speicherplatz durch Packen sparen
Distributoren und Nutzer können Firmwaredateien jetzt per xz -C crc32 komprimieren, denn Linux 5.3 kann so gepackte Dateien beim Laden selbst entpacken. Damit lässt sich der Speicherplatz für die Firmware reduzieren, ohne die viele Treiber die jeweilige Hardware nicht initialisieren können. Durch das Packen konnte der zuständige Entwickler den für Firmware-Dateien benötigten Speicherplatz auf seinem System von 419 auf 130 MByte reduzieren.
