Linux 5.1: Performance-Verbesserungen und neue Speichertechnik

Inhaltsverzeichnis

Nach neun Entwicklungswochen hat Linus Torvalds zum Wochenstart die Version 5.1 des von ihm gestarteten Kernels freigegeben. Wie üblich enthält auch er wieder eine Fülle neuer Features sowie viele neue oder signifikant verbesserte Treiber:

• Mit dem neuen Linux-Kernel wird es deutlich attraktiver, Datenträger mittels asynchronem I/O (AIO) anzusprechen, wie es in der Windows-Welt schon lange üblich ist.

• Linus Torvalds hat eigenhändig Vorbereitungen getroffen, um die Unterstützung für das Dateiformat a.out (Assembler Output) vollständig zu entfernen – das Objektformat also, das in den Anfangstagen von Linux typischerweise für ausführbare Dateien genutzt wurde.

Das Kernel-Log

Die Artikelserie "Die Neuerungen von Linux" beschreibt regelmäßig die Änderungen neuer Linux-Versionen:

• Linux 5.6 (30. März 2020)
• Linux 5.5 (27. Jan. 2020)
• Linux 5.4 (25. Nov. 2019)
• Linux 5.3 (16. Sep. 2019)
• Linux 5.2 (8. Juli 2019)
• Linux 5.1 (6. Mai 2019)
• Linux 5.0 (4. März 2019)
• Linux 4.20 (24. Dez. 2018)

• Einen Meilenstein gab es bei den Umbauten zur Beseitigung des Jahr-2038-Problems.

• Die für Prozessorkern-Designs bekannte Firma ARM hat einen Grafiktreiber beigesteuert. Zwei weitere Treiber für leistungsfähigere Grafikerne von ARM stehen dank der Open-Source-Community bereits in den Startlöchern.

• Geringeren Stromverbrauch und zugleich bessere Performance verspricht der "Timer Events Oriented (TEO)" genannte CPUIdle-Governor.

• Große Fortschritte gab es bei den seit über fünfzehn Jahren vorangetriebenen Bemühungen, Linux Security Modules (LSMs) wie SELinux, AppArmor, Smack durch "Stacking" parallel zu nutzen.

• Linux 5.1 bringt einen ganzen Schwung kleinerer Performance-Optimierungen. Darunter "Airtime Fairness", mit dem sich das Funkspektrum von WLANs besser ausnutzen lässt.

Die folgenden Abschnitte und Artikelseiten liefern zahlreiche Details zu diesen und zahlreichen weiteren Neuerungen von Linux 5.1.

Dinge erledigen, während der Kernel die Daten schreibt oder liest

Linux 5.1 geht eine altbekannte Schwachstelle des Kernels an, denn die neue Version bringt endlich eine zeitgemäße Infrastruktur, um Daten asynchron zu lesen oder zu schreiben. Bei diesem "Asynchronous I/O" (AIO) können Programme eine Übertragung initiieren und dann andere Dinge erledigen, während der Kernel die I/O-Operation ausführt. Unter Windows arbeiten Programme häufig auf diese Weise, weil sie Performance und Reaktionsfreude verbessern kann. Die meiste Linux-Software macht sich AIO hingegen nicht zunutze; das liegt zum Teil an historischen Gründen, vor allem aber an der bisherigen AIO-Infrastruktur des Kernels, die allerlei Tücken birgt; sie steht daher seit Langem in der Kritik, wie die Anfänge der Artikel "Toward non-blocking asynchronous I/O" und "Fixing asynchronous I/O, again)" zeigen, die das angesehene Linux-Online-Magazin LWN.net vor zwei respektive drei Jahren publiziert hat.

Das weitgehend von Facebook-Mitarbeiter Jens Axboe geschriebene "io_uring" soll Linux hier endlich nach vorne bringen. Der Austausch von I/O-Operationen und -Daten mit dem Userspace erfolgt dabei über separate Ringbuffer. Um Latenzen auf ein Minimum zu reduzieren und das Performance-Potenzial moderner Hardware voll ausschöpfen, können Userspace-Anwendung dabei Polling anfordern; durch dieses ständige Abfragen gelangen Programme beispielsweise schneller an gelesene Daten, die der Kernel normalerweise erst zu größeren Bündeln sammeln würde, weil die sonst meist effizienter sind. Bei Facebook-Servern konnte der Entwickler damit einen Leistungszuwachs von 25 bis 33 Prozent messen.

Damit Anwendungsentwickler die neue I/O-Infrastruktur leicht verwenden können, hat Axboe die Userspace-Bibliothek liburing und ein Programmierbeispiel veröffentlicht. Außerdem hat der Entwickler ein Dokument publiziert, in dem er unter anderem Motivation, Design-Ziele, Arbeitsweise und Nutzungsszenarien von io_uring näher erläutert. Einen alternativen Einblick in die Technik liefert die LWN.net-Artikel "Ringing in a new asynchronous I/O API" und "io_uring, SCM_RIGHTS, and reference-count cycles"

Mit dem Gesamtpaket positioniert sich der Kernel letztlich gegen Lösungen wie das Storage Performance Development Kit (SPDK), die den Kernel bei I/O-Operationen umgeht – ähnlich, wie das bekanntere Data Plane Development Kit (DPDK) bislang meist den Netzwerkstack des Kernels ausbootet und daher in Kernel-Kreisen kritisch beäugt wird.

NVDIMMs, a.out vor dem Rauswurf, Jahr-2038-Problem, …

Nicht-flüchtige Speichermodule leichter einbinden

Linux 5.1 kann die Speicherkapazität nicht-flüchtiger Speichermodule (NVDIMMs) jetzt so einbinden, dass Programme oder der Kernel selbst diese Bereiche wie normalen Arbeitsspeicher ansprechen können. Durch dieses von Intel-Entwicklern vorangetriebene Feature müssen Anwendungen nicht mehr groß angepasst werden, um Persistent Memory (PMEM) zu verwenden, auf dem Daten auch beim Kappen der Stromversorgung erhalten bleiben; zu solch raren und meist teuren Speichermodulen zählt etwa Intels im April vorgestelltes Optane DC Persistent Memory. Details zu diesem NVDIMMs hat c't 9/2019 im Artikel "Zwischen RAM und Flash-Speicher: Das bringt Optane DC Persistent Memory" erläutert, den es auch für heise+-Abonnenten gibt.

Apropos NVDIMMs: Der neue Kernel rüstet auch Unterstützung für ACPI 6.3 nach, das unter anderem einige Verbesserungen für solche nicht-flüchtige Speichermodule (NVDIMMs) gebracht hat.

Unterstützung für früher zentrales Dateiformat auf der Abschussliste

Linus Torvalds hat eigenhändig Vorbereitungen getroffen, um die Unterstützung für das Dateiformat a.out (Assembler Output) vollständig zu entfernen. Dieses wurde in der Anfangszeit von Linux für ausführbare Dateien und Objektdateien genutzt; vor mehr als 25 Jahren lernte Linux dann aber das ELF abgekürzte Executable and Linking Format, das schnell zum dominierenden Format aufstieg und diese Position nach wie vor unbestritten hält. Daher war auch niemand aufgefallen, dass der Kernel-Code für Speicherabzüge (Core Dumps) von a.out-Executables nicht mehr korrekt arbeitet. Torvalds hat diesen Code daher kurzerhand entfernt; darüber hinaus hat der den a.out-Support bei x86-Kerneln als veraltet/überholt ("deprecated") gekennzeichnet und lahmgelegt, daher lässt er sich in x86-Kernel-Images nicht mehr einbauen.

Damit will der leitende Kernel-Entwickler schauen, ob sich jemand beklagt, bevor er den zuständigen Code tatsächlich rauswirft. Falls das tatsächlich jemand tut, würde Torvalds womöglich zurückrudern, denn dann wäre das Ganze eine "Regression". Solche versucht Torvalds auf Biegen und Brechen zu vermeiden, daher gilt bei der Linux-Entwicklung schon lange ganz generell: Nur eine Person muss glaubhaft und zeitnah vorbringen, das mit einer neuen Version im Alltagsbetrieb irgendwas nicht mehr geht, was mit der Vorversion funktioniert hat; in dem Fall werden die verantwortlichen Änderungen dann revidiert, sofern das Problem Kernel-seitig nicht anders gelöst werden kann. Der Beklagende muss dabei allerdings zeigen, dass es sich um ein praktisches Problem handelt, und nicht etwa um ein rein theoretisches; außerdem müssen das alte und der neue Kernel-Image möglichst identisch konfiguriert sein. Diese Herangehensweise gilt für alle Kernel-Features mit Ausnahme von jenen im Staging-Bereich, wo es Sonderregeln gibt.

Überfällige Vorbereitungen für das Jahr 2038

Einen Meilenstein gab es bei den Umbauten zur Beseitigung des Jahr-2038-Problems, das 32-Bit-Prozessoren betrifft: Die Kernel-Entwickler haben einen Schwung neuer Funktionsaufrufe (Syscalls) eingebaut, die alten ähneln, aber 64-Bit-Zeitwerte verstehen (u. a. 1, 2, 3, 4, 5, 6, 7, 8). Auch die Netzwerkentwickler haben zwei ähnlich gelagerte Änderung vorgenommen, um ein Y2K38-Problem in ihrem Code anzugehen (1, 2).

Damit ist Kernel-seitig zwar noch nicht alles Nötige getan, aber das meiste. Entwickler von Systembibliotheken und Anwendungen können ihre Software jetzt an die neuen Funktionsaufrufe anpassen, damit ihre Programme 2038 nicht plötzlich denken, es sei 1970 oder gar 1901; das ist auch überfällig, schließlich wird die Kombination von 32-Bit-ARM-Kernen und Linux aktuell noch in Autos oder anderen Embedded Systems verwendet, die wahrscheinlich auch in 19 Jahren noch im Einsatz sind.

Details zur Problematik und den neuen Syscalls liefert der LWN.net-Artikel "Approaching the kernel year-2038 end game." Einige weitere Details finden sich in den Vortragsfolien und einem Video-Mittschnitt des Vortrags "The End of Time, 19 years to go"; er stammt von Arnd Bergmann, der treibende Kraft hinter den Y2K38-Änderungen im Kernel ist.

Grafiktreiber von ARM, Prozessor schlafen lassen, Live Patching, …

Ein Grafiktreiber für ARM-Chip, zwei weitere im Anflug

Die für Prozessorkern-Designs bekannte Firma ARM hat den Grafiktreiber Komeda beigesteuert, der den Mali D71 und dessen Nachfolger unterstützt, wie die Dokumentation erläutert. Das sind "Display Processors", ähnlich wie DP500, DP550 und DP650, die Linux mit dem ebenfalls von ARM zugelieferten Treiber Mali-DP schon länger unterstützt. Die genannten Grafikkerne sind vornehmlich für die Bildausgabe ausgelegt; ihnen fehlt daher eine 3D-Einheit, die bei PC-Grafikchips seit der Jahrtausendwende Usus sind.

3D-Funktionen sind anderen IP-Cores der Mali-Produktpalette vorbehalten, die geläufiger sind und sich auf so manchem Einplatinencomputer finden. Solche Mali-GPU unterstützt Linux nach wie vor nicht von Haus aus. Das sollen die Kernel-Treiber Lima und Panfrost ändern, die zur Aufnahme in Linux 5.2 vorgesehen sind; darauf bauen gleichnamige OpenGL-Treiber zur 3D-Beschleunigung auf, die Mesa 19.1 mitbringen wird. Lima unterstützt dabei "Utgard"-GPUs der 400er-Serie; Panfrost hingegen ist für die neueren "Midgard"- und "Bifrost"-GPUs ausgelegt, die unter den Mali-Modelbezeichnungen T6xx, T7xx, T8xx respektive G3x, G5x, G7x segeln. Bei der Entwicklung dieser Treiber hat ARM allerdings untätig daneben gestanden. Vielmehr entstanden sie weitgehend mit Hilfe von Hardware- und Treiber-Analysen (Reverse Engineering), daher unterstützen beide nur ausgewählte Grafikkerne und längst nicht alle ihrer Funktionen.

Prozessor passend schlafen schicken

Geringeren Stromverbrauch und zugleich bessere Performance verspricht ein "Timer Events Oriented" (TEO) genannter CPUIdle-Governor. Wie der bislang auf vielen Systemen genutzten CPUIdle-Regulator "Menu" entscheidet er bei Untätigkeit darüber, ob und wie tief der Kernel den ganzen Hauptprozessor schlafen schickt, um den Stromverbrauch zu reduzieren. Beide arbeiten sogar mit einer ähnlichen Strategie. Wie der TEO-Entwickler im Commit-Kommentar erläutert, mache der Menu-Governor aber einige fragwürdige Dinge. Das ist indes keine Meinung eines dahergelaufenden Newcomers; wie TEO selbst stammt die Aussage vielmehr vom langjährigen Betreuer des Power-Management-Codes im Kernel, der daher den Code des Menu-Governor gut kennt.

Einer der Hauptunterschiede: TEO verwendet für seine Entscheidungen eine andere Bemessungsgrundlage. Sie soll deutlich besser zur "Tickless"-Arbeitsweise passen, die sich seit Linux 3.10 über die Option CONFIG_NO_HZ_FULL aktivieren lässt, die bei Kernel-Image heutiger Distributionen meist gesetzt ist. Details zu TEO finden sich im Kommentar eines Git-Commits, den darin enthaltenen Dokumentationsänderungen und dem LWN.net-Artikel "Improving idle behavior in tickless systems".

Ob TEO im Einzelfall besser läuft, hängt allerdings stark von den jeweiligen Umgebungsbedingungen ab. Kein Wunder, denn es gibt Software und Workloads, die speziell auf die Arbeitsweise des Menu-Governor abgestimmt sind; das ist auch der Grund, warum das Problem nicht mit inkrementellen Verbesserungen am Menu-Governor angegangen wurde, wie es die Kernel-Entwickler sonst in solchen Situationen tun; der alte Governor wird daher auch weiter im Rahmen des Kernels gewartet.

Neue Wege, den Kernel im Betrieb zu verändern

Beim Kernel Live Patching (KLP), mit dem sich kleinere Kernel-Änderungen (vorwiegend Sicherheitskorrekturen) im Betrieb vornehmen lassen, kann ein Sammel-Patch jetzt alle vorher angewendeten Live-Patches ersetzen. Das ist einem "Atomic Replace" genannten Ansatz zu verdanken, der die Entwicklung solcher "kumulativer Live Patches" erheblich erleichtert; er bringt auch weitere Verbesserungen, die die zugehörige Dokumentation erläutert; weitere Einblicke in die Motivation der verantwortlichen Entwickler liefert der LWN.net-Artikel "Live patching for CPU vulnerabilities".

Endlich: Mehrere Sicherheitsmodule parallel aktivieren

Große Fortschritte gab es bei den seit über fünfzehn Jahren vorangetriebenen Bemühungen, Linux Security Modules (LSMs) wie SELinux, AppArmor, Smack durch "Stacking" parallel zu nutzen. Nachdem das mit einzelnen kleineren LSMs schon klappte, sind jetzt die wesentlichen Vorarbeiten in Linux 5.1 eingeflossen, durch die das bald mit allen LSMs gelingen soll.

Dabei entstand der neue Boot-Parameter lsm=, über den man das oder die aktiven LSMs jetzt beim Systemstart festlegen kann; einen Standardwert lässt sich beim Bau des Kernels über die neue Option CONFIG_LSM vorgeben. Ein Stacking funktioniert bei 5.1 aber nur mit kleineren, wenig bekannten LSMs wie SARA und Landlock; langfristig gelingt es dann aber womöglich, auf einem mit SELinux arbeitenden System vielleicht die Sandbox-Techniken des Paketformats Snap nutzen zu können, das dazu auf AppArmor angewiesen ist.

Performance-Optimierungen, Kompressionslevel bei Btrfs, …

Kleine Performance-Optimierungen hier und da

Der neue Kernel läuft ein klein wenig fixer, denn die Kernel-Hacker haben abermals einen Kniff gefunden, der den Overhead der typischerweise aktiven Spectre-v2-Schutztechnik Retpoline ein wenig reduziert. Diese Änderung hat die Entwickler des GCC zu einer Änderung motiviert, die eine Variante des Kniffs ab Version 8.4 automatisch anwendet.

Beim Aktivieren der Schutzmaßnahme für die Prozessor-Sicherheitslücke Speculative Store Bypass (SSB) können Programmierer über eine weitere Kennzeichnung jetzt festlegen, dass von der Software via exec*() gestartete Anwendungen diesen Schutz nicht zwangsweise übernehmen; diese Programme laufen dadurch flotter. Das ist etwa für Systeme interessant, wo der besonders anfällige Java-Interpreter geschützt werden soll, darüber gestartete Linux-Programme aber nicht.

Memory Compaction, das im Hintergrund der Fragmentierung des Arbeitsspeichers entgegenwirkt, verspricht jetzt deutlich größere Erfolge zu erzielen; dabei soll es den Prozessor sogar weniger belasten als zuvor, daher kann das Ganze die Performance ein klein wenig verbessern.

Änderungen rund um die parallele/asynchrone Hardware-Initialisierung beim Booten können den Start bei Systemen mit vielen SCSI Logical Units erheblich beschleunigen. Die dafür zuständigen Änderungen rüsten zudem den Kernel-Parameter driver_async_probe= nach, mit dem sich flexibler spezifizieren lässt, welche Bausteine der Kernel parallel in Betrieb nehmen darf.

Besitzer von Systemen, die viele CPU-Kerne enthalten und Swap stark nutzen, können sich über eine Optimierung beim Deaktiveren von Swap-Speicher freuen: Ein Swapoff brauchte auf dem Testsystem des zuständigen Entwicklers nicht mehr acht Minuten, sondern nur noch drei.

Funkspektrum von WLANs besser ausnutzen

Nachdem einzelne Treiber bereits "Airtime Fairness" boten, lernten nun der WLAN-Stack des Kernels und dessen Konfigurations-Interface die Technik. WLAN-Treiber, die sich die neue Funktion zunutze machen (etwa ath9k und ath10k), können damit das Funkspektrum besser ausnutzen und so den Summendurchsatz in WLAN-Funkzellen steigern: Langsame Gegenstellen, also alte oder welche mit aktuell schlechter Verbindung, bekommen durch die Technik seltener eine Sendegelegenheit, sodass flottere Clients länger zum Zug kommen. Eine Erklärung des ATF abgekürzten Konzepts findet sich bei Draytek; einige weitere Hintergründe liefert der schon etwas ältere LWN.net-Artikel "Making WiFi fast".

Das bei Linux 4.13 eingeführte Kernel TLS (KTLS) unterstützt jetzt auch Version 1.3 des Transportverschlüsselungs-Protokolls und kann mit 256-Bit-Schlüsseln umgehen.

Ein Mellanox-Entwickler hat das "Devlink health reporting and recovery system" eingebracht, das Überwachungsprogramme zeitnah über Störungen mit der Netzwerkhardware informieren kann.

Darüber hinaus gab es noch zahlreiche andere Neuerungen am Netzwerkcode, die der wichtigste Merge-Commit-Kommentar dieses Subsystems anreißt. Darunter Änderungen, die Performance-Verbesserungen beim Aktualisieren von Regeln für TC (Traffic Control) versprechen; außerdem beherrscht der Bridge-Treiber jetzt Multicast Router Discovery (MRD), wie es RFC4286 definiert.

Kompressionslevel von Btrfs festlegen

Bei Btrfs kann man beim Komprimieren mit Zstd (Zstandard) jetzt den Kompressionslevel vorgeben, um nicht nur Performance- und Packdichte, sondern auch den Speicherverbrauch flexibler gegeneinander abzuwägen zu können.

An der Infrastruktur des Filesystem in Userspace (FUSE) gab es einige Verbesserungen, die Performance und Skalierbarkeit zu verbessern versprechen. Das ist unter anderem für die Storage-Lösungen Ceph oder Gluster interessant, die sich über FUSE-Dateisystemprogramme einbinden lassen.

Anwendungen können mit Fsnotify jetzt einfacher und zuverlässiger überwachen, ob sich etwas am Dateisystem ändert, denn nach langem Anlauf sind Entwickler einige altbekannte Schwachstellen und Funktionslücken beim API angegangen.

Der Kernel bietet jetzt ein neues Programmierinterface zum Einhängen von Dateisystemen. Mit ihm will der zuständige Entwickler eine Reihe von Problemen des bisherigen Mount-APIs aus der Welt schaffen.

Davon abgesehen gab es bei Btrfs, Ext4 und XFS im wesentlichen kleinere Verbesserungen und Korrekturen; wie bei praktisch jeder neuen Kernel-Version waren darunter auch ein paar, durch die es bei bestimmten, oft speziellen und seltenen Umgebungsbedingungen zu Schäden an Meta- oder Nutzdaten kommen kann. Einige weitere Änderungen rund um Dateisysteme nennen die Git-Merge-Kommentare zu CIFS/SMB (1, 2), F2FS, Fscrypt, NFS und NFSd.

Große Datenbündel im Block-Layer effizienter handhaben

Das für Datenträger und Storage-Hardware zuständige Block-Layer kann durch "die neuen Multipage Bvecs" jetzt größere Datenhäppchen besser handhaben, die zusammenhängend im Arbeitsspeicher oder in großen Speicherseiten liegen. Das brächte eine Reihe netter Verbesserungen, wie der Block-Layer-Maintainer Jens Axboe den zuständigen Red-Hat-Entwickler im Kommentar eines Git-Merge lobt. Dieser nennt noch einige weitere Änderungen an der Storage-Infrastruktur.

Über den neuen Kernel-Parameter dm-mod.create= kann man dem Device Mapper jetzt anweisen, ein Device-Mapper-Target beim Booten zusammenzusetzen, das sich auch gleich nutzen lässt – etwa als Root-Dateisystem. Laut den Entwicklern ist das Feature für Android und andere Embedded Systems gedacht, um den Device Mapper dort ohne Initramfs nutzen können. Ein Git-Merge-Kommentar nennt weitere Änderungen bei der "DM" abgekürzten Technik, die bei der Verschlüsselung oder Logical Volume Management (LVM) viel Schwerarbeit erledigt.

Entfernt haben die Entwickler den bislang im SCSI-Subsystem angesiedelten Support für OSD (Object-Based Storage Device) sowie das darauf aufbauende Dateisystem Exofs. Beide haben keine Praxisbedeutung erlangt und Exofs sei ohnehin eher ein Testballon gewesen.

Einige weitere Neuerungen rund um Storage-Infrastruktur nennen Merges der Subsysteme Ceph, Libnvdimm, MMC, MTD und SCSI.

Sicherheitstechniken, eleganter Starten, HDCP 2.2, Zank bei Treibern, …

Sicherheitsverbesserungen von und für ChromeOS

Linux bringt ab 5.1 erstmals das SafeSetID genannte Linux Security Module (LSM) mit, das den Wechsel von User- und Gruppen-IDs regelt. Das bei ChromeOS bereits genutzte LSM kann so etwa unterbinden, dass ein normaler Nutzer ein als Setuid gekennzeichnetes Programm mit Root-Rechten ausführt, wie es normalerweise der Fall wäre.

Von ChromeOS-Entwicklern stammen auch Änderungen, durch die der Kernel autorisierte USB-Geräte nur in Betrieb nimmt, wenn diese an internen Ports hängen.

Das bei Linux 4.11 integrierte und Version 4.14 verbesserte GCC-Plugin Structleak kann nun alle Typen von Variablen explizit initialisieren, die sich der Kernel mit dem Userspace teilt; das kann Informationslecks vermeiden, die Angreifern und Schadsoftware oft dienlich sind.

Einige weitere Änderungen rund um Sicherheit nennen die wichtigsten Merge-Commits der Subsysteme Crypto, GCC-Plugins, Security und TPM.

Grafiktreiber ermöglicht eleganteren Startvorgang

Einige Systeme mit aktuellen Grafikchips von Intel starten mit 5.1 schneller und eleganter, denn Intels Grafiktreiber aktiviert den "Fastboot"-Support nun standardmäßig bei den neuesten Prozessorenen; konkret sind das jene mit Codenamen Valleyview und Cherryview sowie Skylake und neuer, daher gilt das Ganze für Core-i-6000 und jüngere CPUs. Einzelne Distributionen realisieren mit dieser Funktion bereits einen Startprozess, der Bildaussetzer, Flackern oder harte Übergänge vermeidet, wodurch er letztlich so geschmeidig verläuft wie bei modernen Macs. Nahezu alles dazu Nötige war schon seit Linux 4.19 im Kernel; automatisch genutzt wird es aber erst jetzt, nachdem das Ganze erste Feldtests bewältigte und noch etwas Feinschliff erhalten hat.

Ebenfalls neu: Intels Graphics Virtualization Technology (GVT) funktioniert jetzt auch mit Coffee-Lake-CPUs. Außerdem haben die Intel-Entwickler Unterstützung für HDCP 2.2 nachgerüstet; die meisten der dafür zuständigen Änderungen betreffen indes nicht den Grafiktreiber i915, sondern "mei", der Intels Management Engine anspricht (u. a. 1, 2, 3, 4, 5).

PCs mit Radeon-GPUs der Vega-Generation laufen mit 5.1 sparsamer; das ist dem Support für eine "ZeroCore Power Mode" oder "BACO" (Bus Active, Chip Off) genannte Funktion in AMDs Grafiktreiber zu verdanken, durch die der Kernel den Grafikkern weitgehend schlafen legen kann, wenn es nichts zu tun gibt.

Der quelloffenen Nvidia-Treiber Nouveau beherrscht jetzt das seit Linux 4.14 unterstützte Heterogenous Memory Management (HMM); der Treiber kann dadurch etwa Speicherinhalte zwischen Arbeits- und Grafikspeicher spiegeln, was Programmierern den Rückgriff auf GPUs zu Rechenzwecken erleichtert. (u. a. 1, 2, 3).

Das sind nur einige der wichtigsten Änderungen, die es bei Grafiktreibern gab; zahlreiche weitere nennt der wichtigste Merge des Direct Rendering Managers (DRM) von Linux. Darunter Umbauten, die die Multistream-Unterstützung für DisplayPort robuster machen sollen. Der für XGI-Chips zuständige Grafiktreiber Xgifb ist derweil rausgeflogen: Niemand hatte sich darum gekümmert, den schon lange im Staging-Bereich liegenden Code auf Vordermann zu bringen.

Zahlreiche neue und verbesserte Netzwerktreiber

Auch Version 5.1 des Linux-Kernel steigert die Menge der unterstützten Hardware wieder signifikant, denn die Entwickler haben dutzende neue Treiber eingebaut und hunderte verbessert. Dadurch unterstützt Linux jetzt noch mehr von Intel Wi-Fi-6-Chips (802.11ac) der Serien Killer und Wireless-AX 22000 wie die 22260-Modelle (1, 2, 3). Neu ist auch Support für Intels WLAN-Chipfamilie AX210; zu der gehören laut den Codeänderungen auch einige als "Wi-Fi 7" deklarierte 160-MHz-Chips, obwohl von diesem Wi-Fi-Level anderswo noch gar nicht die Rede ist. Neu dabei sind auch ein Treiber für die Mediatek Wi-Fi-4-Chips (802.11n) MT7603E und MT7628/7688 sowie den Ethernet-Controller ENETC von NXP. Der Treiber r8169 nutzt Energy-Efficient Ethernet (EEE) jetzt bei den Realtek-Chips RTL8168f und RTL8168g+.

Unter zahlreichen Änderungen an Audio-Treibern war unter anderem Unterstützung für die professionelle Sound-Hardware RME Fireface UCX Solid (u. a. 1) und Solid State Logic Duende Classic/Mini. Bei einigen Notebooks dürften Funktionstasten zur Helligkeitsregelung, für Vollbildwechsel oder zum Umschalten auf ein externes Display jetzt funktionieren, denn die Eingabetreiber erkennen jetzt einige schon länger dafür spezifizierte Keycodes.

Beschleuniger-Treiber sorgt für Zank

Neu dabei ist auch ein Treiber für den Habana Goya (u. a. 1, 2, 3, 4, 5, 6). Dabei handelt es sich um einen per PCIe angebundene KI-Inferencing-Beschleuniger für Server, der unter anderem mit Nvidias Tesla-Chips konkurriert.

Im Vorfeld der Aufnahme war der Treiber kontrovers diskutiert und vor allem von Entwicklern der Kernel-Grafiktreiber kritisiert worden; letztlich verhallte aber ihre mit schlechten Erfahrungen bei Grafiktreibern begründete Bitte (siehe etwa 1, 2), den Goya-Treiber außen vor zulassen, solange Open-Source-Programme und -Bibliotheken fehlen, um den Treiber und seine Interaktion mit dem Userspace zu testen.

Wie bei jeder neuen Kernel-Version sind die Verbesserungen bei Treibern und ihrer Infrastruktur so zahlreich, dass dieser Text nur einige wichtige Neuerungen exemplarisch vorstellt. Zahlreiche weitere wichtige Änderungen erwähnen Git-Merges der Subsysteme Char, Driver Core, EDAC, IPMI, RDMA, GPIO, Hardware-Monitoring, Input, Media, Mfd, Platform, RTC und Staging.

Wer genauer wissen will, was sich bei einzelnen Treibern getant hat, muss sich die Änderungen am Treibercode ansehen, die in den letzten Wochen erfolgten – etwa mit Git oder dem Git-Webinterface auf Kernel.org. Bei manchen Treibern ist das eine überschaubare Zahl von Commits, bei manchen wird es aber schnell unübersichtlich. Allein 200 Änderungen gilt es beispielsweise beim Iwlfwifi-Treiber zu durchforsten, der moderne und in vielen Notebooks verbauten WLAN-Chips von Intel unterstützt. Bei Grafiktreibern sind es noch mehr Commits; bei den Treibern für moderne AMD-Radeon-GPUs etwas mehr als 350, beim Treiber für Intel-GPUs sogar über 400.

Versiegelung, Raspi 3a+, NXP i.MX8QuadXPlus, …

Allerlei Verbesserungen unter der Haube

Der neue Pidfd Syscall sollte es möglich machen, beim Senden von Signalen wie SIGKILL oder SIGHUP sicherzugehen, dass diese auch tatsächlich an den vogesehenen Prozess gehen. Bei unter Feuer stehenden Systemen können mit den bisherigen Wegen nämlich Race Conditions auftreten, durch die manchmal ein vollkommen unbeteiligter Prozess das Signal erhält und dadurch womöglich abgeschossen wird. Nach Einführung des Ganzen wurden aber noch einige bei LWN.net näher erläuterte Detailprobleme gefunden; einzelne Anpassungen helfen, aber schon bei 5.2 sollen weitere Änderungen folgen.

Die Kernel-Dokumentation liefert jetzt Details zur Arbeitsweise von Energy Aware Scheduling (EAS). Dabei handelt es sich um die jüngst bei Linux 5.0 eingeführte und bei 5.1 weiter verbesserte Technik, durch sie sich der Kernel deutlich mehr für Konzepte wie ARMs big.LITTLE eignet, bei denen in einem Prozessor unterschiedlich schnelle CPU-Kerne arbeiten.

Google-Entwickler haben eine Versiegelungsfunktion für Memfd beigesteuert. Bei Memfd handelt es sich um ein Feature, mit dem mehrere Programme Daten über einen gemeinsam genutzten Arbeitsspeicherbereich austauschen können. Durch die Änderungen soll es jetzt alles bieten, damit Google von der Android-eigenen Technik Ashmem auf Memfd umsteigen kann.

Mit der neuen Konfigurationsoption CONFIG_PRINTK_CALLER übersetzte Kernel-Images versehen ihre Logging-Meldungen mit Thread- oder CPU-IDs. Das soll das Auseinanderdröseln der via dmesg oder /dev/kmsg abrufbaren Informationen erleichtern, denn bei Mehrkernprozessoren vermischen sich dort leicht Ausgaben von Tätigkeiten, die der Kernel parallel ausführt.

Einige Merge-Commits der Subsysteme Ftrace und Perf (1, 2, 3, 4, 5, 6) listen einen ganzen Schwung von Neuerungen bei den Tracing- und Performance-Monitoring-Lösungen – darunter etwa eine Snapshot-Möglichkeit für die Histogramm-Funktion von Ftrace (u. a. 1, 2, 3) und eine Sample-Funktion für perf report.

Einige weitere Änderungen an der Infrastruktur des Kernels nennen Merge-Commits der Subsysteme ACPI, Clock, DMA-Mapping, DMA-Engine, Dokumentation, I2C, IOMMU, IRQ Core, Locking, Kbuild (1, 2), Livepatching, PCI, Pinctl Power-Management.

Unterstützung für Raspberry Pi 3 Model A+

Der Linux-Kernel bringt jetzt alles zum Betrieb auf einem Raspberry Pi 3 Model A+ mit, der keine Ethernet-Schnittstelle hat und weniger Arbeitsspeicher aufweist. Ferner stieß ein Power-Management-Treiber für Raspis zum Kernel; er arbeitet autark, statt das Gros der Arbeit an die Firmware zu delegieren, wie es der Treiber Raspberrypi-Power macht.

Linux unterstützt jetzt auch die SoC-Platformen Renesas RZ/A2M (R7S9210), Renesas RZ/G2E (r8a774c0) und NXP i.MX8QuadXPlus. Das ist aber nur die Spitze des Eisbergs bei neuem ARM-Support, denn die Kernel-Entwickler haben Support für eine ganze Reihe anderer Produkte mit ARM-Kernen nachgerüstet, wie der Git-Pull-Kommentar mit den Updates für ARM SoC Device Trees (DT) zeigt. Einige weitere Neuerungen in diesem Bereich nennen die Git-Merge-Kommentare zu ARM, ARM64, ARM SoC Drivers, ARM SoC Platform und der Commit, der Support für die Milbeaut ARM-SoC-Familie SC2000 nachrüstet.

Beim Betrieb unter Microsofts Virtualisierungslösung Hyper-V stellt Linux jetzt einige weitere Informationen im Sysfs bereit, die beim Eingrenzen von Performance-Probleme helfen können.

Im BPF des Kernels ausgeführter Code kann jetzt einen Spinlock nutzen, um möglichst zügig Zugriff auf eine Datenstruktur zu erhalten, die parallel ausgeführter Code gesperrt hat, weil er dort zugreift. Das kann die Performance der mittlerweile von vielen Subsystemen des Kernels verwendeten BPF Virtual Machine (VM) verbessern, steigert aber zugleich die CPU-Belastung; Details liefert der LWN.net-Artikel "Concurrency management in BPF".

Eine Menge weitere Neuerungen rund um Support für Architekturen, Plattformen und Virtualisierung nennen die Kommentare der Git-Merge-Commits aus den Bereichen Devicetree, EFI, KVM, M68K, MIPS, Parisc, Powerpc, Rproc, RISC-V, s390, Vfio und x86 (1, 2, 3). Diese und ähnliche Linklisten dieses Kernel-Logs nennen übrigens nur Merges, die der Autor für verlinkenswert hielt – zumeist weil sie weitere Änderungen nennen, die für den ein oder anderen Leser relevant sein dürften. Hunderte andere Merges haben diese Hürde nicht geschafft.

Ausblick auf Linux 5.2

Mit der Freigabe von Linux 5.1 beginnt zugleich die "Merge Window" genannte Phase, in der Linus Torvalds das Gros der Änderungen für den Nachfolger integriert. In den nächsten Tagen fließen daher viele tausend Änderungen in den Hauptentwicklungszweig von Linux ein, die Entwickler in den letzten Wochen zur Aufnahme für die nächste Version vorbereitet haben.

Linus Torvalds beendet das Merge Window typischerweise nach zwei Wochen, indem er die erste Vorabversion einer neuen Kernel-Version veröffentlicht. Das läutet zugleich die Stabilisierungsphase ein, die derzeit meist sieben oder acht Wochen dauert. Linux 5.2 erscheint daher wahrscheinlich am 8. oder 15. Juli.

Daten und Zahlen zu den jüngsten Versionen des Linux-Kernels

Kernel- Version	Anzahl Dateien¹	Zeilen Quelltext (Ohne Doku)²	Entwick- lungs- zeitraum	Commits (Ohne Merges)³	Diffstat⁴
Linux 4.14	61.290	25.041.284 (23.050.486)	70 Tage	14.659 (13.452)	23.388 files changed,  719.862 insertions(+),  445.585 deletions(-)
Linux 4.15	62.303	25.364.802 (23.329.451)	77 Tage	16.223 (14.866)	13.265 files changed,  643.912 insertions(+),  320.289 deletions(-)
Linux 4.16	62.915	25.558.805 (23.495.643)	63 Tage	14.896 (13.630)	12.239 files changed,  1.133.069 insertions(+),  939.066 deletions(-)
Linux 4.17	61.362	25.379.564 (23.314.368)	63 Tage	14.745 (13.541)	14.504 files changed,  777.301 insertions(+),  956.941 deletions(-)
Linux 4.18	61.003	25.280.872 (23.183.236)	70 Tage	14.432 (13.283)	13.141 files changed,  583.336 insertions(+),  682.028 deletions(-)
Linux 4.19	61.734	25.588.455 (23.449.221)	70 Tage	15.204 (14.043)	11,693 files changed,  552.223 insertions(+),  244.235 deletions(-)
Linux 4.20	62.481	25.955.520 (23.776.585)	63 Tage	14.995 (13.844)	11402 files changed,  685.027 insertions(+),  317.959 deletions(-)
Linux 5.0	63.135	26.203.035 (23.933.016)	70 Tage	13.921 (12.808)	12.100 files changed, 579.084 insertions(+), 331.570 deletions(-)
Linux 5.1	63.873	26.459.776 (24.141.004)	63 Tage	14.160 (13.034)	11.977 files changed,  545.423 insertions(+),  288.683 deletions(-)
¹ git ls-tree -r --name-only HEAD | wc -l ² find . -type f -not -regex '\./\.git/.*' | xargs cat | wc -l; echo "($(find . -name *.[hcS] -not -regex '\./\.git/.*' | xargs cat | wc -l))" ³ git-log --pretty=oneline vx.(y-1)..vx.(y) | wc -l; echo "($(git-log --pretty=oneline --no-merges vx.(y-1)..vx.(y) | wc -l))" ⁴ git diff --shortstat vx.(y-1)..vx.(y)

Mehr Infos

Den neuen Linux-Kernel herunterladen und einrichten

Direkt nach der Freigabe steht die neue Linux-Version nur über einen Git-Checkout des offiziellen Enwicklerzweigs bereit; die Download-Möglichkeit über die Frontseite von Kernel.org folgt meist erst einige Stunden später, wenn sich die Büros in Europa richtig füllen.

Auf dem Server der Linux-Entwickler finden Sie eine Anleitung, wie Sie die Authentizität und die Unversehrtheit der Kernel-Quellen prüfen; dort gibt es auch ein Skript, das eine Version herunterlädt und diese Aufgaben anschließend durchführt.

Hinweise zur Einrichtung eines eigenen Kernels liefert der c't-Artikel "Linux-Kernel maßgeschneidert". Das darin beschriebene Make-Target make localmodconfig erzeugt weitgehend automatisch eine recht gut auf das jeweilige System zugeschnittene Kernel-Konfiguration, mit der Sie in wenigen Minuten eine neue Linux-Version einrichten können.

Fedora und Rolling-Release-Distributionen wie Arch Linux, Gentoo und OpenSuse Tumbleweed erhalten die neue Linux-Version in den nächsten Tagen und Wochen im Rahmen der regulären Systemaktualisierung. Bei bereits erhältlichen oder kurz vor der Veröffentlichung stehende Releases von Debian, OpenSuse Leap, Ubuntu und den meisten anderen klassisch gewarteten Distributionen macht der Kernel normalerweise keine größeren Versionssprünge; deutlich neuere Kernel erhält man dort meist erst beim Wechsel auf eine neuere Version der Distribution.

Allerlei weitere Informationen zu Linux (dem Kernel, nicht dem Betriebssystem!) liefern der erste, zweite und dritte Teil einer c't-FAQ-Reihe mit "Basiswissen zum Linux-Kernel".

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

(thl)