Die Neuerungen von Linux 4.14 Update

Linux-Kernel 4.14

Trends & News | Kernel-Log

Der ORC Stack Unwinder und allerlei Feintuning versprechen einen Geschwindigkeitszuwachs. Einige Notebooks schlafen mit dem neuen Kernel ganz anders und wachen dadurch schneller auf. Linux bringt jetzt alles mit, um mit zukünftigen Intel-Prozessoren bis zu 4096 Terabyte (4 Petabyte) Arbeitsspeicher anzusprechen.

Das in der ersten Novemberhälfte erwartete Linux 4.14 nutzt auf einigen Notebooks einen Suspend-to-Idle genannten Bereitschaftsmodus, der sich durch flotteres Aufwachen vom traditionell verwendeten Suspend-to-RAM abhebt. Eine neue Debugging-Funktion verspricht, die Geschwindigkeit indirekt zu steigern, denn sie weist weniger Overhead auf als ein Feature, das Distributionen bislang oft nutzen. Die Kernel-Entwickler gehen zudem ein bei der AMD64/x86-64-Einführung noch in weiter Ferne scheinendes Limit an, damit Linux auf zukünftigen Intel-Prozessoren nicht nur 64, sondern bis zu 4096 Terabyte (4 Petabyte) Arbeitsspeicher ansprechen kann. Außerdem haben die Entwickler ein seit Jahren entwickeltes Framework integriert, mit dem Entwickler die Arbeitsspeicherbereiche leichter, flexibler und schneller nutzen können, die unter der Ägide von Hauptprozessor, Grafikprozessor, Crypto-Beschleunigern und ähnlicher Hardware stehen.

Die folgenden Absätze liefern Details zu diesen und weiteren Neuerungen beim Architektur- und Infrastrukturcode. In 4.14 eingeflossene Neuerungen rund um Sicherheit, Netzwerk, Storage und Dateisysteme erläutert dieser schrittweise erweiterte Artikel auf der zweiten und dritten Seite.

c't 25/2016, S. 138
Das auch mit Linux erhältliche Dell XPS 13 (9360) nutzt jetzt einen anderen Schlafzustand. (Bild:  c't 25/2016, S. 138 )

Einige moderne Notebooks steuern mit 4.14 nicht mehr Suspend-to-RAM (aka STR oder ACPI S3) an, wenn sie diese in den Bereitschaftsmodus schicken. Vielmehr schlafen sie per Suspend-to-Idle, aus dem die Geräte viel schneller aufwachen – zugleich ist die Leistungsaufnahme in diesem Schlafzustand aber höher; daher belastet er den Akku stärker.

Das Ganze betrifft etwa das mit Linux und Windows erhältliche Ultrabook Dell XPS 13 (9360), aktuelle Surface-Notebooks von Microsoft und einige andere Laptops, die zumeist besonders sparsame Prozessoren enthalten und zu den teuren Modellen zählen. Im Windows-Betrieb wechseln diese Notebooks standardmäßig in einen Stromsparmodus, den Microsoft "Modern Standby" nennt, die Linux-Welt aber Suspend-to-Idle (abgekürzt S2I oder S2Idle). Diesen seit Linux 4.10 unterstützten Schlafzustand nutzt der Kernel bei solchen Notebooks jetzt automatisch. Ein Grund dafür: Hersteller testen vielfach nur den standardmäßig genutzten Schlafmodus mit dem beigepackten Betriebssystem. Bei Geräten mit Modern Standby bleiben dadurch Fehler in den Codepfaden der Firmware unentdeckt, die sich um Suspend-to-RAM kümmern. Dieser traditionell für den Bereitschaftsmodus genutzte Schlafzustand arbeitet auf Suspend-to-Idle-Geräten daher manchmal unzuverlässig oder gar nicht.

Notebooks wachen aus dem Suspend-to-Idle meist so schnell auf, dass sie bereits voll einsatzbereit sind, sobald man das Display aufgeklappt und die Hände auf die Tastatur gelegt hat. Das gelingt, weil Suspend-to-Idle die Komponenten eines Systems lediglich mit den zur Laufzeit nutzbaren Schlafmodi so tief wie möglich schlafen legt. Android-Geräte nutzen solch einen Ansatz schon lange. WLAN-Verbindungen bleiben beim Suspend-to-Idle erhalten; daher muss man auch nicht auf eine Neuanbindung ins Internet warten. Die Leistungsaufnahme im Schlafzustand ist bei diesem Ansatz allerdings höher als beim Suspend-to-RAM. Schließlich erhalten bei ihm nur der Arbeitsspeicher und einige zum Wecken benötigte Komponenten noch Strom.

Windows-Anwender müssen sich mit dem höheren Stromverbrauch im Schlafzustand abfinden, denn Windows wechselt immer in den Schlafzustand, den die Firmware vorgibt. Mit Linux kann man Suspend-to-RAM hingegen auch auf Suspend-to-Idle-Notebooks nutzen: Sie müssen lediglich deep in /sys/power/mem_sleep schreiben, damit das System beim Wechsel in den Bereitschaftsmodus wieder ins Suspend-to-RAM geht. Falls Sie später wieder Suspend-to-Idle verwenden wollen, schreiben Sie s2idle in die Pseudodatei.

Zu einer der wichtigsten Änderungen von 4.14 zählt der ORC Stack Unwinder, der einen weiteren Weg zur Erzeugung besser lesbarer Stacktraces stellt. ORC ist aber keineswegs nur für Entwickler relevant, die bei einem Kernel-Fehler die Namen der Funktionen sehen wollen, über die der Kernel-Code zum Fehlerpunkt gelangt ist. Der neue Analyseweg zum Aufschlüsseln von Call Traces verbessert indirekt auch die Performance bei der alltäglichen Nutzung, denn er braucht keine Frame Pointer, die den Kernel größer und langsamer machen – Fedora, Ubuntu und einige andere Distributionen aktivieren diese aber derzeit nichtsdestotrotz, damit der Frame Pointer Unwinder des Kernels die Call Traces aufschlüsselt. Laut einem Commit-Kommentar kann ein Umstieg auf ORC daher die Performance um 1 bis 3 Prozent steigern; bei besonders Kernel-lastigen Aufgaben können es sogar zwischen 5 und 10 sein, wie auch der Hilfetext zum neuen Unwinder erwähnt.

ORC steht für "Oops Rewind Capability". Das von ihm genutzte Format ist eine vereinfachte Version von DWARF, dem unter Linux meistgenutzten Format für Debugging-Informationen. Beide Formate sind für Binaries gedacht, die im bei Linux gängigen Executable and Linkable Format (ELF) vorliegen.

Die Performance-Steigerung war aber nicht der Hauptgrund zur Entwicklung von ORC; vielmehr wollten die Programmierter einen Stack Unwinder schaffen, der verlässlicher arbeitet als der Frame Pointer Unwinder. Dadurch soll ORC dann letztlich Kernel Live Patching (KLP) robuster und flexibler machen; auch Profiler profitieren vom neuen Ansatz. ORC dürfte aber noch etwas Feinturing brauchen, bevor Distributoren darauf umsteigen. Weitere Details zu diesen und anderen Aspekten von ORC erläutern ein Blog-Eintrag eines Entwicklers, ein LWN.net-Artikel, die Kernel-Dokumentation sowie die Kommentare und Inhalte einiger Commits (u. a. 1, 2, 3, 4, 5).

Der x86-64-Architekturcode von Linux kann jetzt bis zu 4096 Terabyte (4 Petabyte) Arbeitsspeicher adressieren; Programmen steht sogar ein virtueller Adressraum von 128 Petabyte bereit. Bislang war bei 128 Terabyte virtuellem Adressraum und 64 Terabyte physischem Speicher Schluss – letztgenanntes Limit erreichen einige Hardware-Hersteller gerade mit ihren stärksten Systemen.

Dank 5-Level Paging Support kann Linux 4.14 bis zu 4096 Terabyte Arbeitsspeicher ansprechen.
Dank 5-Level Paging Support kann Linux 4.14 bis zu 4096 Terabyte Arbeitsspeicher ansprechen. (Bild:  git.kernel.org )

Mit aktuellen Prozessoren ist da aber weiter Schluss, denn die zur Adressierung von mehrerer Petabyte Arbeitsspeicher zuständigen 5 Level Pages Tables erfordern eine CPU mit einer "LA57" genannten Technik. Laut den Commit-Kommentaren will Intel diese Funktion bei zukünftigen Prozessoren implementieren, anfangs womöglich nur bei einzelnen und teuren Modellen der Xeon-Baureihe. Die bei LWN.net näher erläuterten 5 Level Pages Tables harmonieren derzeit auch noch nicht mit Xen, wohingegen KVM die Technik bereits unterstützt (u. a. 1, 2).

Die zweite Generation der Control Groups bietet mit dem "Cgroup v2 Thread Support" jetzt ein Interface zur Handhabung von Threads. Dieses entstand nach jahrelangen Debatten, die bereits parallel zur Aufnahme der Cgroups v2 in Linux 4.5 aufflammten. Ein Cgroup-v2-Controller zum Regeln der Prozessornutzung war damals schon weit gediehen. Er musste aber draußen bleiben, weil die Entwickler nicht überein kamen, wie Threads von Prozessen gehandhabt werden sollten.

Einige Diskussionsteilnehmer forderten, Prozesse und ihre Threads in unterschiedliche Cgroups stecken zu können. Das war bei den Cgroups v2 aus verschiedenen Gründen nicht vorgesehen – unter anderem, weil es das User-Interface verkompliziert hätte, die Performance verschlechtern würde und bei vielen Controllern gar nicht umsetzbar sei. Nach langem hin und her und einigen Experimenten entstand mit dem Thread Support jetzt ein Kompromiss, den LWN.net näher beschreibt. Auf diesen Code soll ein CPU-Controller für Cgroup v2 aufbauen, der bei 4.15 folgen dürfte. Das renovierte Cgroup-Interface dürfte dadurch endlich durchstarten können, denn dann stünden alle wesentlichen Controller auch via Cgroup v2 zur Verfügung.

Nach mehreren Entwicklungsjahren ist eine Infrastruktur zum Heterogeneous Memory Management (HMM) eingeflossen. Sie soll Programmierern eine deutlich simplere und zugleich performantere Nutzung der verschiedenen Arbeitsspeicherbereiche ermöglichen, die sich in modernen Systemen finden. Das ist etwa für Berechnungen mit C++, OpenCL oder CUDA wichtig, denn durch HMM kann der Grafikprozessor leichter Datenstrukturen lesen und schreiben, die im Hauptspeicher liegen. Dadurch müssen Programme beispielsweise die zu verarbeitenden Daten nicht mehr im Arbeitsspeicher verankern (Pinning) oder in den Speicher der Grafikkarte kopieren. Durch HMM können zudem auf dem Hauptprozessor aufgeführte Programme leichter auf den Grafikspeicher zugreifen, um dort ein Ergebnis abzuholen, das die GPU berechnet hat. Das Ganze ist nicht nur für Grafik- beziehungsweise Stream-Processing-Karten interessant, sondern auch für Host Bus Adapter (HBAs), Crypto-Beschleuniger, FPGAs oder DSPs. Details hierzu liefert ein Inhalt und der ausfürhliche Kommentar eines Commit des zuständigen Entwicklers sowie ein älterer LWN.net-Artiklel.

Zwischen den Patches am Xen-Code war das seit längerem entwickelte Backend für die "Pvcalls" (u. a. 1, 2). Bei diesen handelt es sich um einen im Xen-Blog näher beschriebenen Kommunikationsweg, der POSIX-Aufrufe von der DomU zur Verarbeitung an die Dom0 leitet. Das soll Overhead bei Virtualisierung mit Xen reduzieren und so die Geschwindigkeit steigern.

Linux bringt jetzt einen "Hyper-V Transport for Virtual Sockets" mit. Dieser stellt einen Kommunikationsweg, über den sich auf einem Windows-Host laufenden Anwendungen effizienter und ohne Netzwerkverbindung mit einem Linux austauschen können, das unter Microsofts Hypervisor in einer Virtual Machine (VM) läuft.

Unter den wichtigsten Umbauten an KVM (u. a. 1, 2) waren gleich mehrere, um die Performance von Nested Virtualization zu steigern – also den Betrieb einer VM innerhalb einer anderen VM, die direkt auf dem Host läuft.

Performance-Verbesserungen sind das Ziel der im Android-Umfeld entstandenen Funktion "Allow remote cpufreq callbacks" (u.a. 1, 2, 3). Durch sie kann der Prozess-Scheduler einen CPU-Kern gleich zum Hochtakten auffordern, wenn er einen Prozess an diesen delegiert. Bislang konnte der Scheduler das nur beim lokalen CPU-Kern bewirken. Prozesse liefen dadurch beim Start oder Verschieben auf einem anderen Kern zuerst nur langsam, falls sich dieser gerade in einem langsamen und stromsparenden Betriebszustand befand. Ein LWN.net-Artikel erläutert Details.

Vermutlich wird kaum ein Leser hier ein System mit tausenden von Prozessorkernen sein eigen nennen. Aber falls doch: Unter den Änderungen am Scheduler waren einige, die den Start des Kernels auf solchen Systemen deutlich beschleunigen sollen.

Einige Umbauten sollen die Swap-Perforamnce deutlich steigern.
Einige Umbauten sollen die Swap-Perforamnce deutlich steigern. (Bild:  git.kernel.org )

Beim Memory-Management-Code gab es zahlreiche Detailverbesserungen, von denen einige die Performance unter bestimmten Umgebungsbedingungen steigern – teilweise sogar deutlich. Details hierzu finden sich in Commit-Kommentaren zu Features wie "add /proc/pid/smaps_rollup", "page_alloc: rip out ZONELIST_ORDER_ZONE", "add swap readahead hit statistics", "add sysfs interface for VMA based swap readahead", "VMA based swap readahead", "Choose swap device according to numa node", "delay splitting THP after swapped out" oder dem auch bei LWN.net erläuterten "membarrier: Provide expedited private command". Einen Performance-Gewinn verspricht auch eine neue Cache-Funktion im Red-Black-Tree-Code des Kernels.

Beim Subsystem für Dokumentation gab es weniger Änderungen als zuletzt. Zufällig hat eine Reihe von Entwicklern aber einige wichtige Dokumente grundlegend überarbeitet und auf einen aktuellen Stand gehievt, darunter etwa die Beschreibungen zu den unterstützten Schlafzuständen, dem Microcode-Loader, der SMB3-Unterstützung, dem bei 4.13 eingefügten Writeback-Fehlerdatentyp errseq_t sowie den Locking-Mechanismen atomic_t, RCU (Read-Copy-Update) und Rtmutex.

Durch die neue "Crossrelease"-Funktion kann Lockdep jetzt in noch mehr Situationen automatisch prüfen, ob Kernel-Code die gesetzte Locks korrekt sperrt und entsperrt.

Bei der Kernel-Infrastruktur und den Werkzeugen für Performance-Monitoring und -Analysen mit Perf gab es wieder zahlreiche wichtige Verbesserungen, die ein Commit-Kommentar erläutert. Darunter sind neben Namespace-Support beispielsweise auch Branch-Type Profiling/Tracing Support (u. a. 1, 2, 3, 4). Durch einige Erweiterungen können Tools wie perf mem jetzt auch physische Speicheradressen ausgeben (u. a. 1, 2, 3, 4, 5). Außerdem kann perf annotate jetzt mit einem Symbol direkt anzeigen, wenn der Codefluss durch eine Macro-Operation Fusion optimiert wurde.

Details zu anderen Neuerungen im Bereich Infrastruktur finden sich in den wichtigsten Commits der Subsysteme ACPI, Cgroups, Device Tree (DT), Device Properties Framework, EFI, IOMMU, Kbuild, Kselftests, Locking, PCI, Percpu, Power Management, Thermal, RCU und VFIO. Das sind übrigens nur jene Merges dieses Bereichs, die der Autor aus dem ein oder anderen Grund für erwähnenswert hielt; einige Dutzende andere haben diese Hürde nicht geschafft. Das gleiche gilt auch für andere Aufzählungen dieser Art, die dieser Text enthält.

Linux 4.14 bringt Support für den Raspberry Pi Zero W und eine Reihe weiterer Single-Board-Computer (SBC).
Linux 4.14 bringt Support für den Raspberry Pi Zero W und eine Reihe weiterer Single-Board-Computer (SBC). (Bild:  git.kernel.org )

Einen kleinen Performance-Gewinn verspricht die Unterstützung für Process Context ID (PCID) im x86-Code. Durch diese in neueren Intel-Prozessoren zu findende Technik kann der Kernel häufig vermeiden, die im TLB (Translation Lookaside Buffer) zu Caching-Zwecken gespeicherten Daten zu verwerfen, wenn der Kernel von einem Prozesskontext zu einem anderen wechselt. Bei anderen Architekturen heißt das "Address space ID". Die Entwickler nennen die Unterstützung für Intels Implementation allerdings "unorthodox": Die Hardware hat einige Beschränkungen; daher müssen die Entwickler zu Tricks greifen, damit PCID tatsächlich die Geschwindigkeit steigert. Falls PCID Probleme bereitet, kann man es über die neue Boot-Option nopcid deaktivieren.

Vollkommen unabhängig davon gab es im x86-Code noch einige Optimierungen an der Hyper-V-Unterstützung. Diese versprechen nicht nur, Hypercalls zu Microsofts Hypervisor zu beschleunigen (u. a. 1, 2), sondern auch das Leeren des TLB in darunter laufenden Virtual Machines (VMs) schneller und besser zu machen (u. a. 1, 2).

Der Kernel enthält jetzt Device-Tree-Bindings und eine Konfiguration für den Raspberry Pi Zero W (u. a. 1, 2, 3). Neu dabei ist auch Support für die Single-Board-Computer Banana Pi R2 (BPI-R2) und Banana Pi M3, M2M and M64.

Weitere Details zu Änderungen am Architektur-Code nennen die Merge Commits zu den Subsystemen ARC, ARM (Core, Drivers, Device Tree, Platforms), ARM64, MIPS, Parisc, PowerPC, S390 (1, 2), SPARC und x86 (ASM, Cache Quality Monitoring, FPU, Memory Management).

Schrittweise aktualisierter Text zu Linux 4.14

Am 16. September hat Linus Torvalds die erste Vorabversion von Linux 4.14 freigegeben. 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 passieren danach nur noch in Ausnahmefällen.

Das Kernel-Log kann daher schon jetzt die Neuerungen der am 6. oder 13. November erwarteten Kernel-Version beschreiben. Das erfolgt wie immer schrittweise. Dieser Text wird daher zwischen Erstpublikation und der Fertigstellung des neuen Kernels mehrfach erweitert, um nach und nach die wesentlichen Änderungen von Linux 4.14 zu beschreiben.

Im neuesten Text-Update kamen Abschnitte zu neuen Sicherheits-Features dazu, die Sie auf der ersten Artikelseite finden. Ältere Textpassagen zu Sicherheitstechniken, Dateisystemen, Storage- und Netzwerk-Support finden Sie auf den folgenden Seiten. Vor die Abschnitte mit bislang beschriebenen Änderungen werden wir noch Absätze stellen, die Verbesserungen bei Treibern beschreiben. Details zur Versionshistorie des Artikels finden Sie am Artikelende

Kommentare

Kommentare lesen (82 Beiträge)

Anzeige