Seite 6: Ressourcenregelung, Speichereinbindung & Feintuning

Inhaltsverzeichnis

Ressourcenregelung für Threads

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 laut dem Cgroup-Maintainer 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.

Externen Speicher leichter einbinden

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ührliche Kommentar eines Commit des zuständigen Entwicklers sowie ein älterer LWN.net-Artikel.

Verbesserungen zur Virtualisierung

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 bietet einen Kommunikationsweg, über den sich auf einem Windows-Host laufende 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.

Feintuning für mehr Geschwindigkeit

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.

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 gesetzten 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.

Feintuning am Architekturcode

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).