/Linux-Kernel 4.14: Performance-Optimierungen im Netzwerk- und Ext4-Code

Linux-Kernel 4.14: Performance-Optimierungen im Netzwerk- und Ext4-Code

Ein Zerocopy-Ansatz im Netzwerkcode verspricht einen Performance-Gewinn. Den sollen auch Optimierungen am Ext4-Dateisystem erzielen. Btrfs und SquashFS lernen einen neuen und flexibleren Kompressionsalgorithmus.

Der im November erwartete Linux-Kernel 4.14 wird AMDs Secure Memory Encryption (SME) unterstützten. Einige der neueren AMD-Prozessoren können damit Teile des Arbeitsspeichers verschlüsseln, um beispielsweise die RAM-Inhalte virtueller Maschinen zu schützen.

Neu in Kernel 4.14 ist auch der ORC Stack Unwinder. Er stellt einen weiteren Weg zur Erzeugung von leicht lesbaren und verlässlichen Stacktraces bereit, die beim Auftreten von Kernel-Fehlern die Ursachenforschung erleichtern. Indirekt kann ORC auch die Performance verbessern, denn er arbeitet ohne Frame Pointer; diese drücken die Performance ein wenig, sind in manchen Distributions-Kernel aber dennoch aktiv, um die Fehlerfindung mit Stacktraces zu erleichtern.

Diese und zahlreiche andere Neuerungen sind jetzt absehbar, denn Linus Torvalds hat Samstagnacht die erste Vorabversion von Linux 4.14 veröffentlicht. Knapp zwei Wochen nach der Fertigstellung von Linux 4.13 hat er damit die Aufnahme der wesentlichen Änderungen für Version 4.14 abgeschlossen.

Das Kernel-Log der c’t kann daher bereits jetzt einen Einblick in die wichtigsten Neuerungen des vermutlich am 6. oder 13. November veröffentlichten Linux 4.14 liefern. Das erfolgt wie gewohnt schrittweise nach Gebieten. Erst ein Update wird daher Details zu den oben angerissenen und zahlreichen anderen Neuerungen liefern. Stattdessen konzentriert sich der folgende Text fürs Erste auf die Verbesserungen bei Netzwerk, Storage-Support und Dateisystemen. Bevor es ins Detail geht, die wichtigsten Neuerungen dieser Subsysteme in Kurzform:

Linux kann dank “Socket Sendmsg MSG_ZEROCOPY” jetzt von Programmen aufbereitete Daten direkt per TCP verschicken, ohne diese zuerst aus dem Speicherbereich einer Anwendung (dem “Userspace”) in jenen das Kernels (“Kernelspace”) kopieren zu müssen. Das vermeidet Arbeit und soll so die Geschwindigkeit steigern. Der Trick ist keineswegs neu, denn per sendfile() kann Linux schon länger Daten verschicken, ohne diese erst in den Kernelspace kopieren zu müssen. Dieser Ansatz funktioniert aber nur mit Dateien. Der neue setzt hingegen bei sendmsg() an und eignet sich dadurch für Daten, die ein Programm im Speicher hat. Das können einmalig zum Versand aufbereitete Daten sein, wenn beispielsweise ein CMS auf Anfrage eines Nutzers eine individuelle Webseite kompiliert und ausliefert.


MSG_ZEROCOPY soll den Prozessor in bestimmten Situationen deutlich entlasten.

MSG_ZEROCOPY soll den Prozessor in bestimmten Situationen deutlich entlasten.

Bild:
kernel.org

Laut dem zuständigen Entwickler kann der Zerocopy-Ansatz die Prozessorlast in Micro-Benchmarks deutlich verringern. Bei Tests mit weitgehend aus dem Produktionsbetrieb übernommenen Workloads hätte die Technik einen Performance-Vorteil von 5 bis 8 Prozent erzielt. Der Kernel kann das Ganze aber nicht automatisch nutzen: Programme müssen die die Zerocopy-Funktion unterstützten und explizit anfordern, schließlich dürfen sie den Speicherbereich nicht modifizieren, bevor der Kernel die darin enthaltenen Daten auf den Weg geschickt hat.

Weitere Hintergründe zu MSG_ZEROCOPY und dessen Einsatz finden sich in dem Kommentar eines Merge Commit, einigen Commit-Kommentaren (1, 2, 3, 4, 5) und einem Artikel von LWN.net. Noch mehr Details liefern die Videoaufzeichung eines Vortrags des zuständigen Entwicklers sowie die dort gezeigten Präsentationsfolien und ein zugehöriges Paper.

Die Netzwerk-Schnellstraße Express Data Path (XDP) lässt sich dank “XDP Generic” seit Linux 4.12 mit beliebigen Netzwerk-Schnittstellen verwenden. Jetzt beherrscht der dafür verantwortliche Code auch XDP_REDIRECT und unterstützt virtuelle Netzwerkgeräte. Darüber hinaus implementiert der Tun-Treiber nun XDP, was die Performance bei Tests um mehr als 40 Prozent verbessern konnte.


Linux 4.14 enthält Grundlagen für einen derzeit entwickelten Kernel Proxy.

Linux 4.14 enthält Grundlagen für einen derzeit entwickelten Kernel Proxy.

Bild:
www.mail-archive.com

Einige in 4.14 eingeflossene Umbauten schaffen Grundlagen, auf die ein derzeit in Entwicklung befindlicher “Kernel Proxy” aufbauen soll; er soll SSL-Proxies, Application Firewalls und L7 Load Balancer beschleunigen, indem er den Overhead beim Layer-7-Processing reduziert.

Linux 4.14 bringt zahlreiche Verbesserungen am Code des BPF – der aus dem klassischen Berkeley Packet Filter (BPF) hervorgegangenen Virtual Machine, mit der XDP, Seccomp, Perf, tcpdump und anderer Kernel- und Userspace-Code den oftmals dynamisch erzeugten Programmcode ausführen, dem diese Techniken oft die Schwerarbeit aufbürden. Zum BPF-Code stieß beispielsweise ein JIT (Just in Time) Compiler für 32-Bit-ARM-Prozessoren, der die Ausführungsgeschwindigkeit auf solchen CPUs steigern soll. Die BPF-VM beherrscht neben den Instruktionen BPF_JGT (>), BPF_JGE (>=), BPF_JSGT (s>) und BPF_JSGE (s>=) nun auch die Gegenstücke BPF_JLT (<), BPF_JLE (<=), BPF_JSLT (s<) und BPF_JSLE (s<=); das soll Overhead vermeiden, der bislang durch Spiegeln der Vergleichsargumente entstand. Ebenfalls neu: Eine zum Speichern von Geräte-Referenzen gedachte “Devmap” und die zum SK-Redirect geeignete “Sockmap”.

Einige weitere Neuerungen rund um Netzwerk-Support des Kernels finden sich im Kommentar eines Merge-Commits, mit denen die wesentlichen Änderungen am Netzwerkcode zum Kernel stießen. Mit ihnen haben die Entwickler den IRDA-Code, mit dem sich Netzwerkverbindungen über Infrarot-Sender und -Empfänger aufbauen lassen, in den Staging-Bereich verschoben. Dieser Umzug in den Bereich für Code mit bekannten Qualitätsmängeln läutet den Rauswurf des IRDA-Netzwerk-Supports ein; Anwender, die das verhindern wollen, müssen jetzt an die Kernel-Hacker herantreten. Damit rechnen diese aber nicht, denn bislang habe sich auch niemand beschwert, dass der diese Tage ohnehin eher exotische Kommunikationsweg in aktuellen Linux-Versionen bereits eine Weile nicht mehr richtig funktioniert.

Das Btrfs-Dateisystem und das bei vielen Live-Linuxen verwendete Kompressions- und Image-Dateisystem SquashFS können Daten nun mit Zstandard (kurz: Zstd) komprimieren. Dieser verlustfreie Kompressionsalgorithmus zeichnet sich durch eine Reihe verschiedener Kompressionslevel aus, durch die sich Packdichte sowie der zum Komprimieren benötigte Zeit- und Rechenaufwand flexibel gegeneinander abwägen lassen. Dabei soll Zstd ähnlich schnell komprimieren können wie LZ4 und zugleich eine an LZMA heranreichende Qualität erreichen; beim Dekomprimieren sollen alle drei auf einem ähnlichen Niveau liegen und damit knapp doppelt so schnell sein wie das von gzip verwendete Zlib. Das behauptet zumindest Nick Terrell, der Support für Zstd in den Kernel eingebracht hat und genau wie der Zstd-Entwickler bei Facebook in Lohn und Brot steht.


Zstd-Dokumentation

Ergebnisse eines Vergleichstests der Zstd-Entwickler.

Bild:
Zstd-Dokumentation

Terrell hat darüber hinaus auch das Xxhash Modul eingebracht, das Support für die von Zstd verwendeten Hash-Algoithmen xxh32 und xxh64 nachrüstet. Diese sind nicht für kryptografische Zwecke geeignet, sondern nur zur Prüfsummenberechnung – dabei sollen sie aber deutlich schneller arbeiten als Checksumming-Algorithmen wie CRC32.

Hintergründe zum Ganzen erläutern die Zstd-Website und ein Merge-Commit-Kommentar. Etwas mehr in die Tiefe sowie Messergebnisse zu xxh32/xxh64 und zstd finden sich in den Kommentaren der Commits, mit denen Xxhash und Zstd in Linux einflossen; weitere liefern die Änderungen, die Zstd-Support in Btrfs und SquashFS nachgerüstet haben.

Beim Ext4-Dateisystem gab es diesmal nur wenige Änderungen. Eine davon beseitigt ein Skalierungsproblem. Dadurch soll die Menge der maximal pro Sekunde erzeugten Dateien auf Systemen mit vielen CPU-Kernen teilweise drastisch steigen – laut dem zuständigen Entwickler legte das Dateisystem in einem Benchmark sogar um das Zehnfache zu.

Einen Performance-Zuwachs beim Anlegen von Dateien verspricht auch ein Schwung von Änderungen am Quota-Code, mit dem sich die Menge der von Anwendern verwendbaren Dateisystem-Ressourcen limitieren lässt. Der zuständige Subsystem-Entwickler erwähnt Berichte, denen zufolge Ext4 in Tests ungefähr um den Faktor 2 zulegte.

Die Eignung für Android-Geräte zu verbessern ist eines der Ziele der Änderungen an F2FS (Flash-Friendly File System). Das soll beispielsweise durch Patches erreicht werden, die die Performance beim Zusammenspiel mit der Embedded-Datenbank SQLite verbessern sollen (u. a. 1, 2). Außerdem beherrscht das für Flash-Datenträger optimierte Dateisystem jetzt sowohl Project Quota als auch Journalled Quota.

Durch Umbaunten an CIFS kann das Dateiystem nun auch erweiterte Attribute (EAs/Xattr) auf Samba- und Windows-Freigaben lesen und schreiben, die SMB2 und neuer verwenden.

Neben den erwähnten Änderungen gab es noch zahlreiche weitere, die die Kommentare der Merge-Window-Commits zu den Dateisystemen Btrfs, FUSE, GFS2, NFS (1, 2), NFSd, Orangefs, Overlayfs/OVL, XFS nennen.


Eine der Optimierungen an BFQ beschleunigte einen Test um 125 Prozent.

Eine der Optimierungen an BFQ beschleunigte einen Test um 125 Prozent.

Bild:
kernel.org

Unter den wesentlichen Änderungen am Block-Layer (1, 2, 3) sind zahlreiche Optimierungen, die Performance-Probleme des bei Linux 4.12 integrierten Storage-I/O-Schedulers BFQ (Budget Fair Queueing) beheben. Darunter ist beispielsweise eine für Flash-Datenträger relevante Optimierung, die bei einem Benchmark auf einem Einplatinencomputer den Durchsatz um 125 Prozent steigern konnte; außerdem haben die Entwickler die Dokumentation zum Feintuning von BFQ verbessert. Ein anderer Satz von Änderungen beseitigt ein Skalierungsproblem in Blq-Mq, durch das ein Aktivieren von Inflight Accounting die Datenträger-Performance erheblich reduziere.

Allerlei Detailverbesserungen gab es auch bei CEPH, Device Mapper, Libata, Libnvdimm, MD, MDT, MMC, Pstore, SCSI und der bei Linux 4.13 grundlegend überarbeiteten Writeback-Fehlerhandhabung.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne Doku)²
Entwick-
lungs-
zeitraum
Commits
(Ohne
Merges)³
Diffstat⁴
Linux 4.7 54.400 21.720.955
(19.971.725)
70 Tage 13.433
(12.283)
9909 files changed,
575.816 insertions(+),
277.305 deletions(-)
Linux 4.8 55.503 22.071.048
(20.266.168)
70 Tage 14.552
(13.382)
11.483 files changed,
662.558 insertions(+),
314.177 deletions(-)
Linux 4.9 56.223 22.348.356
(20.520.460)
70 Tage 17.392
(16.214)
11.416 files changed,
713.497 insertions(+),
436.209 deletions(-)
Linux 4.10 57.202 22.839.659
(20.864.595)
70 Tage 14.249
(13.029)
11.913 files changed,
806.420 insertions(+),
312.218 deletions(-)
Linux 4.11 57.994 23.137.402
(21.132.076)
70 Tage 13.891
(12.724)
12.528 files changed,
550.108 insertions(+),
252.364 deletions(-)
Linux 4.12 59.845 24.170.860
(22.125.075)
63 Tage 15.736
(14.570)
12.531 files changed,
1.342.677 insertions(+),
309.204 deletions(-)
Linux 4.13 60.582 24.767.008
(22.698.219)
63 Tage 14.150
(13.006)
10.898 files changed,
878.431 insertions(+),
282.283 deletions(-)
Linux 4.14-rc1 61.277 25.018.217
(23.030.518)
n. n. 12.352
(11.550)
11.677 files changed,
676.894 insertions(+),
436.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)

(thl)

Versionshistorie dieses Artikels

Der obige Text wird zwischen Freigabe der ersten Vorabversion und Fertigstellung von Linux 4.14 mehrfach erweitert, um schrittweise alle wichtigen Änderungen der neuen Kernel-Version zu erläutern. Einmal publizierte Absätze ändern oder erweitern wir nur bei triftigen Gründen. Zur Freigabe des neuen Linux stellen wir den Text allerdings um, damit Absätze zu den wichtigsten Neuerungen am Anfang stehen.

  • 2017-09-17, 16:15 – v1.0: Erste Version, die sich auf die Neuerungen bei Storage-Support, Dateisystemen und Netzwerk konzentriert.