Linux LZ4: Resync auf v1.10.0 macht Dekompression bis zu 21% schneller

Samsung-Ingenieur Michal Wilczynski hat am 25. September 2026 eine Serie aus 9 Patches veröffentlicht. Sie bringt den LZ4-Kompressionscode des Linux-Kernels auf den Stand von Upstream LZ4 v1.10.0. Die Kopie im Kernel liegt 488 Upstream-Commits zurück. Das Update beschleunigt die Dekompression bei jeder getesteten Blockgröße, um bis zu 21%. Außerdem schließt es eine Sicherheitslücke im alten Code.

LZ4 ist ein Kompressionsformat, das auf Geschwindigkeit ausgelegt ist statt auf kleine Dateien. Der Kernel nutzt es dort, wo Daten ständig gepackt und entpackt werden müssen. Beispiele sind komprimierter Arbeitsspeicher und schreibgeschützte Dateisysteme.

Wie weit das LZ4 des Kernels zurückliegt

Der Kernel lädt LZ4 nicht als externe Bibliothek. Er trägt eine eigene Kopie des Codes in seinem Quellbaum, und diese Kopie ist auseinandergedriftet. Laut Wilczynskis Anschreiben sind die beiden Hälften auf unterschiedlichen Ständen eingefroren.

Teil	Version im Kernel	Aus dem Jahr
Dekompressor	LZ4 v1.8.3	2018
Kompressor	LZ4 v1.7.3	2017
Upstream-Ziel	LZ4 v1.10.0	22. Juli 2024

Das Upstream-Projekt veröffentlichte v1.10.0 am 22. Juli 2024 und nannte es die "Multicores edition". Laut den Release Notes umfasst es mehr als 600 Commits. Die wichtigste Neuerung ist Multithread-Kompression. Zudem gilt die Wörterbuch-Kompression nun als stabil.

Das Problem mit den Grenzprüfungen

Das stärkste Argument im Anschreiben betrifft die Sicherheit, nicht die Geschwindigkeit. Die abgespaltene Funktion LZ4_decompress_fast() im Kernel prüft nie, ob sie innerhalb ihres Puffers schreibt. "Das abgespaltene LZ4_decompress_fast() hat keine Grenzprüfungen, daher läuft beschädigte Eingabe in beide Richtungen über den Ausgabepuffer hinaus", schrieb Wilczynski.

Eine Grenzprüfung ist ein Test, der verhindert, dass Code über das Ende eines Speicherblocks hinaus liest oder schreibt. Fehlt sie, können beschädigte oder bösartige komprimierte Daten den Dekompressor dazu bringen, fremden Speicher zu überschreiben. Das ist der klassische Weg zu einem Absturz oder einer Sicherheitslücke. Der Resync ersetzt den abgespaltenen Code durch die Upstream-Version.

Der Kompromiss zwischen Geschwindigkeit und Größe

Das Anschreiben meldet schnellere Dekompression bei jeder getesteten Blockgröße, von 4K bis 256K. Die Zuwächse für die LZ4-Bibliothek selbst waren:

• 4K-Blöcke: 11% schneller
• 16K-Blöcke: 21% schneller, der größte Zuwachs
• 64K-Blöcke: 17% schneller
• 256K-Blöcke: 10% schneller

Tests über EROFS, ein schreibgeschütztes Dateisystem, zeigten 11% bei 4K und 14% bei 64K.

Der Preis ist die Größe. Auf x86_64 wächst der kompilierte Code von 45K auf 89K. Das Anschreiben führt das größtenteils auf den vollständigeren Parser von Upstream zurück.

Die Serie ändert auch die Pflege des Codes. Der Kernel würde die Upstream-Dateien unverändert übernehmen statt eines von Hand bearbeiteten Forks. "Ein Resync wird zu einer Verzeichniskopie", schrieb Wilczynski.

Was das für Entwickler bedeutet

Prüfen Sie zuerst, ob Sie LZ4 im Kernel überhaupt nutzen. Das Anschreiben nennt vier Nutzer: zram, erofs, f2fs und lib/decompress_unlz4. zram ist ein komprimiertes Swap-Gerät, das im RAM liegt. EROFS ist ein schreibgeschütztes Dateisystem, und F2FS ist ein Dateisystem für Flash-Speicher.

Wenn Sie zram mit LZ4 betreiben, erreicht Sie diese Änderung am wahrscheinlichsten. Swapping auf zram passiert unter Speicherdruck, wenn jeder CPU-Zyklus zählt. Ein zweistelliger Zuwachs bei der Dekompression kann sich dort als reaktionsschnelleres System zeigen. Führen Sie cat /sys/block/zram0/comp_algorithm aus, um zu sehen, welchen Algorithmus Ihr zram-Gerät verwendet.

Wenn Sie Images auf EROFS ausliefern, gilt der Zuwachs von 11-14% für das Lesen von Dateien. Das zählt wohl am meisten, wenn viele kleine Blöcke auf einmal gelesen werden, etwa beim Booten. Messen Sie auf Ihrer eigenen Hardware, bevor Sie damit rechnen. Die Zahlen im Anschreiben stammen aus dessen eigenem Testaufbau.

Wenn Sie für sehr kleine Geräte bauen, beachten Sie das Wachstum der Codegröße um 44K. Auf einem Embedded-Kernel mit knappem Flash-Budget lohnt es sich, das zu messen.

Betrachten Sie die Korrektur der Grenzprüfungen als den eigentlichen Grund, diese Änderung zu wollen. Jeder Pfad, der Daten von der Festplatte oder aus dem Netzwerk mit dem alten schnellen Decoder entpackt, vertraut seiner Eingabe vollständig. Bis die Serie aufgenommen ist, sollten Sie in Ihrem eigenen Kernel-Code die geprüften Dekompressionsfunktionen bevorzugen.

Dies ist eine Patch-Serie in der Prüfung, kein gemergter Code. Beobachten Sie die linux-kernel-Liste auf Antworten der Maintainer. Sie entscheiden, wann die Serie in einem Release landet.