Linux LZ4 : la resynchronisation en v1.10.0 accélère la décompression jusqu'à 21%

L'ingénieur de Samsung Michal Wilczynski a publié le 25 septembre 2026 une série de 9 correctifs. Elle met à jour le code de compression LZ4 du noyau Linux avec la version amont LZ4 v1.10.0. La copie du noyau a 488 commits de retard sur l'amont. La mise à jour accélère la décompression pour chaque taille de bloc testée, jusqu'à 21%. Elle comble aussi une faille de sécurité dans l'ancien code.

LZ4 est un format de compression conçu pour la vitesse plutôt que pour des fichiers compacts. Le noyau l'utilise là où les données doivent être compressées et décompressées en permanence. C'est le cas de la mémoire compressée et des systèmes de fichiers en lecture seule.

Le retard du LZ4 du noyau

Le noyau ne charge pas LZ4 comme une bibliothèque externe. Il embarque sa propre copie du code dans son arborescence source, et cette copie a dérivé. Selon la lettre de présentation de Wilczynski, les deux moitiés sont figées à des points différents.

Partie	Version dans le noyau	Date
Décompresseur	LZ4 v1.8.3	2018
Compresseur	LZ4 v1.7.3	2017
Cible amont	LZ4 v1.10.0	22 juillet 2024

Le projet amont a publié la v1.10.0 le 22 juillet 2024, sous le nom de "Multicores edition". Ses notes de version indiquent qu'elle intègre plus de 600 commits. Sa principale nouveauté est la compression multithread. Elle fait aussi passer la compression par dictionnaire en version stable.

Le problème des contrôles de limites

L'argument le plus fort de la lettre de présentation porte sur la sécurité, pas sur la vitesse. La fonction LZ4_decompress_fast() issue du fork du noyau ne vérifie jamais si elle écrit à l'intérieur de son tampon. "Le LZ4_decompress_fast() forké n'a aucun contrôle de limites, donc une entrée corrompue déborde du tampon de sortie dans les deux sens", a écrit Wilczynski.

Un contrôle de limites est un test qui empêche le code de lire ou d'écrire au-delà de la fin d'un bloc de mémoire. Sans lui, des données compressées endommagées ou malveillantes peuvent pousser le décompresseur à écraser de la mémoire sans rapport. C'est la voie classique vers un plantage ou une faille de sécurité. La resynchronisation remplace le code forké par la version amont.

Le compromis entre vitesse et taille

La lettre de présentation fait état d'une décompression plus rapide pour chaque taille de bloc testée, de 4K à 256K. Les gains pour la bibliothèque LZ4 elle-même sont les suivants :

• Blocs de 4K : 11% plus rapide
• Blocs de 16K : 21% plus rapide, le gain le plus important
• Blocs de 64K : 17% plus rapide
• Blocs de 256K : 10% plus rapide

Les tests via EROFS, un système de fichiers en lecture seule, ont montré 11% à 4K et 14% à 64K.

Le prix à payer est la taille. Sur x86_64, le code compilé passe de 45K à 89K. La lettre de présentation attribue l'essentiel de cette hausse à l'analyseur plus complet de l'amont.

La série change aussi la façon dont le code est maintenu. Le noyau reprendrait les fichiers amont tels quels, au lieu d'un fork modifié à la main. "Une resynchronisation devient une copie de répertoire", a écrit Wilczynski.

Ce que cela signifie pour les développeurs

Vérifiez d'abord si vous utilisez LZ4 dans le noyau. La lettre de présentation cite quatre utilisateurs : zram, erofs, f2fs et lib/decompress_unlz4. zram est un périphérique de swap compressé qui réside en RAM. EROFS est un système de fichiers en lecture seule, et F2FS est un système de fichiers conçu pour le stockage flash.

Si vous utilisez zram avec LZ4, c'est le changement qui a le plus de chances de vous concerner. Le swap vers zram intervient sous pression mémoire, quand chaque cycle CPU compte. Un gain de décompression à deux chiffres peut alors se traduire par un système plus réactif. Lancez cat /sys/block/zram0/comp_algorithm pour voir quel algorithme utilise votre périphérique zram.

Si vous livrez des images sur EROFS, le gain de 11-14% s'applique à la lecture des fichiers. Il compte sans doute le plus quand de nombreux petits blocs sont lus en même temps, comme au démarrage. Faites vos propres mesures sur votre matériel avant de compter dessus. Les chiffres de la lettre de présentation proviennent de sa propre configuration de test.

Si vous compilez pour de très petits appareils, notez la hausse de 44K de la taille du code. Sur un noyau embarqué au budget flash serré, cela vaut la peine d'être mesuré.

Voyez la correction des contrôles de limites comme la vraie raison de vouloir ce changement. Tout chemin qui décompresse des données venant du disque ou du réseau avec l'ancien décodeur rapide fait entièrement confiance à son entrée. Tant que la série n'est pas intégrée, privilégiez les fonctions de décompression avec contrôles dans votre propre code noyau.

Il s'agit d'une série de correctifs en cours de revue, pas de code fusionné. Surveillez la liste linux-kernel pour les réponses des mainteneurs. Ce sont elles qui décideront quand la série arrivera dans une version.