Die Neuerungen von Linux 4.18 Update

Linux-Kernel 4.18

Trends & News | Kernel-Log

Linux 4.18 bringt Support für den Raspberry Pi 3B und einen ARM-SOC, der in leistungsstarken und mit Windows ausgelieferten Notebooks stecken soll. Restartable Sequences versprechen effizienteres Locking.

Der am 6. oder 13. August erwartete Linux-Kernel 4.18 unterstützt den Raspberry Pi 3B deutlich besser. Er bringt auch erste Teile des Supports für einen ARM-Prozessor, der bei Notebooks zum Einsatz kommen soll, die mit x86-Modellen konkurrieren sollen. Linus Torvalds wurde da gleich hellhörig, denn er hofft schon länger auf solche Geräte. Nach mehreren Entwicklungsjahren unterstützt der Kernel nun auch Restartable Sequences, mit denen Anwendungsentwickler den Locking-Overhead reduzieren können.

Linux 4.18 ist die erste Kernel-Version, die die Bastelcomputer Raspberry Pi 3B und 3B+ von Haus aus halbwegs ordentlich unterstützt. Das ist unter anderem Patches zu verdanken, die Unterstützung für den im März vorgestellten Raspberry Pi 3B+ nachrüsten (u. a. 1, 2, 3). Dank einer weiteren Änderung weiß der Kernel jetzt auch dessen seit 4.17 prinzipiell unterstützten GPIO-Expander anzusprechen, der auch auf dem Raspberry Pi 3B (ohne Plus) sitzt. Dadurch lassen sich nun die für WLAN, Bluetooth, HDMI-Erkennung und Aktivitäts-LED benötigten GPIOs steuern. Beim LAN78XX-Treiber für den Gigabit-Ethernet-Controller des B+ lauern aber wohl noch mehr Bugs als gewohnt, wie ein an den Änderungen beteiligter Entwickler uns wissen ließ.

Linux 4.18 bringt deutlich bessere Unterstützung für die beiden Varianten des Raspberry Pi 3B.

Diese Fortschritte sind vor allem für Distributionen wie Debian, Fedora & Co. wichtig, die Raspis mit ihren regulären ARM- beziehungsweise ARM64-Kerneln unterstützen wollen. Für Nutzer spezialisierter Raspi-Distributionen wie Raspbian sind die Verbesserungen im offiziellen Linux-Kernel nur relevant, wenn sie einen Mainline-Kernel einsetzen möchten: Diese Distributionen verwenden spezielle für Raspis gebaute Kernel, bei denen die Entwickler zahlreiche Raspi-spezifsche Umbauten und Erweiterungen vorgenommen haben. Die fließen vielfach nur träge in offizielle Linux-Versionen ein, weil die Patches gar nicht eingereicht werden oder den Qualitätsansprüchen der Entwickler um Linus Torvalds nicht genügen. Manchmal ist das Missfallen so groß, dass unabhängige Programmierer die von Raspbian & Co. verwendeten Erweiterungen und Treiber verwerfen und von Grund auf neuen Code schreiben, um Komponenten der verschiedenen Raspis zu unterstützen.

Das Kernel-Log

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

Der bessere Raspi-3-Support stieß mit Erweiterungen an den ARM Device Trees zum Kernel, die auch Support für den Steam Link von Valve und die Nintendo NES/SuperNES Classic Edition gebracht haben. Bei einigen dieser und anderer erstmals unterstützter SOCs bedeutet das aber nur, dass der Linux-Kernel jetzt irgendwie mit diesen Plattformen klarkommt; zum Alltagseinsatz fehlen jedoch oftmals Treiber für wichtige oder weniger wichtige Komponenten.

Das gilt auch für den ebenfalls neuen Support für den Qualcomm SDM845, der auch als Snapdragon 845 bekannt ist. Olof Johansson erwähnt beiläufig, dass man damit noch nicht viel machen könne, allerdings werde Support für USB, GPU und andere Komponenten langsam eintrudeln; wenn das so weiter gehe, werde der offizielle Kernel diesen SOC bald ziemlich gut unterstützen. Linus Torvalds wurde da gleich hellhörig und fragte, ob das nicht der SoC einiger mit Windows ausgelieferten Notebooks mit ARM-Prozessor sei. Solche halbwegs leistungsstarken und mit x86-Geräten vergleichbare Notebooks wünscht er sich schon länger, wie er 2014 in einem Interview mit c't verriet.

Linus Torvalds hofft auf Notebooks mit ARM-Prozessoren, die normalen (x86-)Notebook ähneln. (Bild: LKML-Archiv bei lore.kernel.org )

Daraufhin entstand eine Mail-Wechsel, in dem Heiko Stübner anmerkte, auch das mit Rockchip RK3399 ausgestattete Samsung Chromebook Plus dürfte die Wünsche von Torvalds halbwegs erfüllen. Johansson widersprach nicht, erwähnte aber, dass die Situation bei Grafiktreibern beim Snapdragon 845 besser sei, denn für deren Adreno-GPUs gibt es mit Freedreno einen quelloffenen Grafiktreiberstack; bei Geräten mit dem SOC habe er zudem berechtigte Hoffnungen, dass sich Secure Boot ausschalten lasse.

Nach vielen Jahren Entwicklungsarbeit bringt Linux 4.18 erstmals einen Funktionsaufruf für "Restartable Sequences" mit. Der Syscall ist für mit mehreren Threads arbeitende Anwendungen gedacht, die mit möglichst wenig Overhead eine Datenstruktur verändern wollen. Mit den Restartable Sequences gelingt das ohne klassisches Locking, indem der Userspace-Code bei der Ausführung darauf spekuliert, dass ihm kein anderer Thread in die Quere kommt; falls das doch passiert, fängt er nochmal von vorn an.

Der Programmierer kann das Verfahren über den neuen Syscall nutzen. Dieser legt einen von Anwendung und Kernel geteilten Speicherbereich an, bei dem der Kernel die Zugriffe durch seine "Per-CPU"-Funktion sichert. In dem geteilten Speicherbereich hinterlegt der Entwickler eine Sequenz von Instruktionen, die eine CPU-lokale Datenstruktur verändert – zum Beispiel ein Element in eine Linked List einfügt. Die eigentliche Änderung darf erst mit letzten, nicht unterbrechbaren (also "atomaren") Instruktionen dieser Sequenz erfolgen. Während der Ausführung des Programmcodes kann allerdings ein anderer Thread auf dieselbe Datenstruktur zugreifen und so die Restartable Sequence unterbrechen. Wenn das passiert, springt der Kernel in den Abbruch-Teil der Restartable Sequence; das Userspace-Programm muss diesen Fall dann handhaben und kann die Sequenz gegebenenfalls neu starten.

Auszug einiger Testergebnisse des Entwicklers der Restartable Sequences. (Bild: git.kernel.org – d7822b1e24f2 )

Im Idealfall ist so ein Restart der Sequenz aber nicht nötig, sodass die Änderung erfolgt, ohne das der normale Locking-Overhead anfällt. Das kann die Performance in bestimmten Fällen um ein Vielfaches steigern. Das zeigen Messungen des vor allem durch seine Arbeit an LTTng (Linux Trace Toolkit Next Generation) bekannten Entwicklers, der jahrelang auf die Integration der Restartable Sequences hingearbeitet hat. Ihm zufolge läuft ein "Per-CPU statistic counter increment" genannter Micro-Benchmark auf einem 32-Bit-ARM-Prozessor 11 mal schneller, auf einem 64-Bit-x86-System rund 7,7 mal so schnell. Der Commit-Kommentar nennt Testergebnisse spezieller Aufgaben, bei denen sich noch größere Vorteile zeigen; er erwähnt aber auch einen Praxistest von Facebook, bei dem der Gesamtvorteil im einstelligen Prozentbereich lag.

Der Kernel unterstützt Restartable Sequences bislang im Architekturcode für ARM, MIPS, Powerpc und x86. Wie man diesen begrenzten atomaren Kontext für Userspace-Programme verwendet, erläutert ein Kommentar im Kernel-Code. Ein im letzten Herbst veröffentlichter LWN.net-Artikel liefert einige Hintergründe zum Ganzen; nach dessen Publikation wurde die Implementation aber nochmal verändert, wodurch die dort erwähnten "ops vectors" wieder vom Tisch sind.

Der Control Group (Cgroup) Memory Controller bietet jetzt den Parameter memory.min, über den der Admin noch zuverlässiger als bei memory.low sicher stellen kann, dass der Prozessgruppe mindestens die im Parameter festgelegte Arbeitsspeichermenge zur Verfügung steht.

Ftrace kann durch die neuen "trace_marker trigger" Aufgaben ausführen (etwa Histogramme erzeugen), wenn bestimmte Umgebungsbedingungen eintreten.

Neu sind auch die "Power Domain Performance Levels", die das Powermanagement-Subsystem in die Lage versetzen, das Performance/Stromsparniveau des ganzen Systems samt seiner Peripherie-Geräte zu regeln. Diese bei LWN.net näher erläuterte Erweiterung ist unter anderem für SOCs wichtig, bei denen mehrere Komponenten zusammenhängen und daher beispielsweise koordiniert heruntergetaktet oder ausgeschaltet werden müssen, um die Leistungsaufnahme zu reduzieren.

Ferner gab es einige bei LWN.net erläuterte Umbauten (u. a. 1, 2), um 32-Bit-Linux-Kernel Jahr-2038-fest zu machen.

Weitere Informationen zu den architekturspezifischen Änderungen nennen die wichtigsten Merge-Commits am Code für ARM (Core, SOC [1, 2], SOC DT, SOC Drivers), ARM64, m68k, m68knommu, microblaze, MIPS, PowerPC, RISC-V, S390, x86 (Boot, Cache, DAX, Debug, Hyperv, RAS). Änderungen rund um die Infrastruktur erwähnen Merge-Commits für ACPI (1, 2), Core RCU, Char, Cgroups, DMA Mapping, Device Tree, Dokumentation, EDAC, EFI, Kbuild (1, 2), Kconfig, KVM (1, 2), Locking Core, PCI, Printk, Perf (1, 2), Power Management (1, 2), IRQ, IOMMU, Scheduler, Selftests, Siginfo, Thermal Core, Thermal Soc, Timer, Trace, VFIO, Vhost. Das sind übrigens nur jene Merges, die der Autor aus dem ein oder anderen Grund für verlinkenswert hielt, weil sie für manche Leser relevante Informationen enthalten. Einige Dutzend andere Merges rund um Architektur oder Infrastruktur haben diese Hürde nicht geschafft. Das gleiche gilt auch für andere Aufzählungen dieser Art, die dieser Text enthält.

Schrittweise aktualisierter Text zu Linux 4.18

Support für eine neue Generation von AMDs Vega-Grafikkernen und die Grafikhardware des Intel/AMD-Radeon-Kombiprozessors sind zwei Highlights von Linux 4.18. Die am 6. oder 13. August erwartete Kernel-Version bringt zudem Grundlagen für Bpfilter mit: einen neuen Mechanismus für das Filtern von Netzwerkpaketen, der nach dem Willen einiger Entwickler die Netfilter-Infrastruktur ersetzen soll, auf die Firewall-Lösungen wie Iptables und Nftables bislang zurückgreifen (siehe c't 13/2018, S. 88 und c't 15/2018, S. 34). Neu dabei sind auch Treiber für Valves Steam-Controller und Support für ein Qualcomm-SoC mit ARM-Innenleben, das für Notebooks gedacht ist.

Diese und weitere Neuerungen von Linux 4.18 sind seit dem 17. Juni absehbar, als Linus Torvalds die erste Vorabversion dieser Kernel-Version freigegeben hat. Damit hat er die "Merge Window" genannte Phase des Entwicklungszyklus abgeschlossen, in der er alle wesentlichen Umbauten für eine neue Kernel-Version vornimmt. Größere, erwähnenswerte Änderungen erfolgen danach nur in Ausnahmefällen; es passiert auch nur äußerst selten, dass die Entwickler eine umfangreichere, im Merge Window integrierte Änderung vor der Fertigstellung deaktivieren oder gar entfernen.

Das Kernel-Log der c't kann daher bereits jetzt die Neuerungen der nächsten Linux-Version in einem detaillierten Text beschreiben. Er wird zwischen Erstpublikation und der Fertigstellung des neuen Kernels mehrfach erweitert, um die wesentlichen Änderungen der verschiedenen Kernel-Bereiche schrittweise in leichter handhabbaren Mengen zu beschreiben. Aus diesem Grund wird das Kernel-Log den Bpfilter auch unabhängig von den anderen Änderungen im Netzwerkbereich erläutern.

Der Newsticker von heise online erwähnt größere Erweiterungen des Textes zum neuen Linux-Kernel, die Sie immer auf der ersten Artikelseite finden. Ältere Textpassagen stehen auf den folgenden Seiten. Details zur Versionshistorie des Artikels liefert das Changelog am Artikelende.

Kommentare

Kommentare lesen (164 Beiträge)

Anzeige