Une série de trois correctifs publiée sur la liste de diffusion du noyau Linux le mercredi 26 août 2026 rend le zstd interne au noyau nettement plus rapide en supprimant un travail qu'il ne fallait jamais refaire. Le code zstd du noyau vérifie à l'exécution si le processeur gère les instructions BMI2, et il effectue cette vérification à chaque création d'un contexte de compression ou de décompression. Les correctifs d'Usama Arif ne la font plus qu'une seule fois. Sur un test crypto_acomp, le résultat est une baisse de soixante et onze pour cent du temps de décompression et de dix huit pour cent du temps de compression.
The short answer
Usama Arif a publié le 26 août 2026 une série de trois correctifs sur la liste de diffusion du noyau Linux qui empêche le zstd interne de redétecter la prise en charge BMI2 du processeur à chaque création d'un contexte de compression ou de décompression. Le chemin de code existant déclenche deux instructions CPUID sérialisantes avec sorties de machine virtuelle inconditionnelles, à chaque contexte. SquashFS le fait pour chaque bloc décompressé, et EROFS, Btrfs et F2FS créent tous un contexte par opération. Sonder une seule fois a donné 71 pour cent de temps de décompression en moins et 18 pour cent en compression. Les correctifs sont en relecture.
Votre processeur ne va pas perdre la prise en charge de BMI2 pendant que la machine tourne. Le noyau vérifiait quand même, à chaque contexte zstd créé, et il s'avère que cette vérification coûtait assez cher.
Le défaut qui n'en est pas un
La bibliothèque zstd interne au noyau embarque deux chemins de code pour le décodage entropique : un générique, et un qui utilise les instructions de manipulation de bits BMI2. BMI2 est arrivé avec Intel Haswell en 2013 et AMD Excavator en 2015, et une même image de noyau doit démarrer sur du matériel plus ancien que les deux, donc choisir entre ces chemins à l'exécution est la bonne décision.
L'erreur est plus subtile. Ce choix est effectué à l'intérieur de la création de contexte, ce qui veut dire qu'il est refait pour chaque contexte. Or la prise en charge d'une instruction par le processeur n'est pas une propriété qui change d'un contexte au suivant.
Rien n'est incorrect ici. Le code donne la bonne réponse à chaque fois. Il la donne simplement quelques millions de fois plus souvent que la question n'est posée.
Pourquoi une vérification de capacité devient du temps réel
Deux éléments rendent CPUID exceptionnellement cher pour ce qu'il fait.
Le premier est que CPUID est une instruction sérialisante. Elle vide le pipeline et force le processeur à abandonner l'exécution dans le désordre qui porte l'essentiel de ses performances. Comptée en cycles plutôt qu'en instructions, elle pèse bien plus lourd qu'il n'y paraît.
Le second est celui qui compte en 2026 : sous virtualisation, CPUID provoque une sortie de machine virtuelle inconditionnelle. L'invité bascule vers l'hyperviseur, l'hyperviseur traite l'instruction, la main revient. Cet aller retour coûte plusieurs ordres de grandeur de plus que tout le calcul effectué autour. Le chemin signalé déclenche deux instructions CPUID sérialisantes par création de contexte : une machine virtuelle paie donc ce coût deux fois, à chaque fois, indéfiniment.
Reste à compter les contextes. SquashFS en crée un pour chaque bloc décompressé, et les blocs SquashFS sont petits par conception. EROFS, Btrfs et F2FS initialisent chacun un contexte par opération. Sur un hôte de conteneurs qui lit une image SquashFS ou EROFS dans un invité, le motif approche le pire cas : de minuscules unités de travail, une forte rotation des contextes, et une sortie d'hyperviseur agrafée à chacune.
La mesure, et le crédit à lui accorder
Les chiffres viennent d'un test crypto_acomp : soixante et onze pour cent de temps de décompression en moins, dix huit pour cent de temps de compression en moins.
L'asymétrie entre ces deux nombres est ce qui rend le résultat crédible. Compresser est un travail réellement lourd, donc un surcoût fixe par contexte n'en représente qu'une petite fraction et le supprimer déplace le total de dix huit pour cent. Décompresser en zstd est rapide, ce qui veut dire que le même surcoût fixe pèse une part bien plus grande du total, et le supprimer déplace le chiffre de soixante et onze pour cent. C'est exactement la forme attendue si le diagnostic est juste.
C'est aussi pourquoi il ne faut pas espérer soixante et onze pour cent sur votre propre stockage. crypto_acomp sollicite le chemin de compression via l'interface crypto du noyau avec très peu d'autre chose autour, ce qui est idéal pour isoler ce surcoût et non représentatif d'un système en fonctionnement. Une lecture réelle fait des entrées sorties disque, de l'allocation de pages et des copies, autant d'éléments qui diluent l'amélioration. Le gain sera maximal là où les blocs sont les plus petits et la machine virtualisée, et modeste sur un volume Btrfs en grandes lectures séquentielles sur machine physique.
Cela s'inscrit dans une bonne année du noyau
Une série de changements récents trouve de gros chiffres en supprimant du travail redondant plutôt qu'en ajoutant de l'ingéniosité. Btrfs qui double les entrées sorties directes et accélère fsync cinq fois dans Linux 7.3, un blocage KSM de 705 millisecondes ramené à 1,67 milliseconde et Torvalds remontant un écran noir sur Xe jusqu'à un seul appel à round_up partagent le même caractère : une petite hypothèse ancienne qui a cessé d'être vraie ou ne l'a jamais été, posée sur un chemin chaud où personne n'a pensé à regarder.
Celui ci illustre bien pourquoi cela se reproduit. La vérification était correcte, d'apparence peu coûteuse, et enfouie dans une fonction d'initialisation. On ne la trouve qu'en profilant l'appelant, pas en lisant le code.
Que faire
Rien, et c'est la bonne nouvelle.
Les correctifs ont été publiés pour relecture le 26 août 2026 et ne sont pas fusionnés. Il n'existe aucun réglage, aucune option de montage, aucun changement de configuration. L'interface est inchangée et le correctif entièrement interne : quand il arrivera, il arrivera, simplement.
Si vous exploitez des systèmes de fichiers compressés en zstd dans des machines virtuelles, en particulier des images de conteneurs SquashFS ou EROFS, cela vaut la peine de surveiller les journaux de version du noyau, car votre charge se situe précisément là où le changement rend le plus. Et si vous voulez savoir si votre matériel emprunte seulement le chemin BMI2, le drapeau se lit dans /proc/cpuinfo : sur tout ce qui a été acheté depuis dix ans, la réponse est oui.
Sources et pour aller plus loin
- Patches Provide For Much Faster In-Kernel Zstd Due To Embarrassingly Bad Inefficiency, Phoronix, 26 août 2026
- zstd: probe BMI2 support only once, série de correctifs d'Usama Arif, LKML, 26 août 2026
- Fil de discussion sur les correctifs zstd BMI2 du noyau, Linux.org
Questions fréquentes
Qu'est ce que BMI2 et pourquoi le noyau le vérifie t il ?
BMI2 est un jeu d'instructions de manipulation de bits, présent sur les Intel Haswell et suivants et sur les AMD Excavator et suivants. Le décodage entropique de zstd effectue beaucoup d'extractions de champs de bits, précisément ce que ces instructions accélèrent, donc la bibliothèque embarque deux chemins de code et choisit le plus rapide quand le matériel le permet. La détection à l'exécution est la bonne conception ici, car une même image de noyau doit démarrer aussi bien sur des processeurs antérieurs à 2013 que sur les actuels. Le problème n'a jamais été la vérification elle même mais sa fréquence : le noyau la relançait à chaque création de contexte au lieu d'une fois à l'initialisation.
Pourquoi une vérification CPUID coûte t elle assez cher pour compter ?
Sur machine physique, c'est simplement du gâchis. CPUID est une instruction sérialisante : elle vide le pipeline et bloque le réordonnancement dont le processeur tire l'essentiel de sa vitesse, donc elle coûte bien plus que son nombre d'instructions ne le laisse penser. En virtualisation, c'est bien pire, car CPUID provoque une sortie de machine virtuelle inconditionnelle : l'invité bascule vers l'hyperviseur, celui ci traite l'instruction et rend la main. Le chemin de code signalé déclenchait deux instructions CPUID sérialisantes par contexte. Le faire une fois au démarrage est invisible. Le faire pour chaque bloc décompressé par un système de fichiers transforme une vérification triviale en part mesurable du travail total.
Quels sous systèmes en profitent réellement ?
Ceux qui créent un contexte zstd par unité de travail plutôt qu'une fois pour toutes. SquashFS est le pire cas cité, car il passe par ce chemin pour chaque bloc qu'il décompresse, et les blocs SquashFS sont petits par conception. EROFS, Btrfs et F2FS initialisent tous un contexte par opération et paient donc le coût de façon répétée. Le code crypto/zstd est dans la même situation, ce qui explique que le test crypto_acomp employé pour la mesure le sollicite. En pratique, cela couvre les images de conteneurs et les images système en lecture seule sur SquashFS et EROFS, les volumes Btrfs montés avec compression zstd, et F2FS sur mémoire flash.
Verrai je vraiment 71 pour cent sur mes propres machines ?
Traitez ce chiffre comme une borne haute issue d'un test qui isole le chemin concerné. crypto_acomp mesure compression et décompression via l'interface crypto du noyau avec très peu d'autre chose autour, donc le surcoût fixe par contexte y représente une part inhabituellement grande du total. Une charge réelle lit aussi du stockage, alloue des pages, copie des données et fait quelque chose du résultat, ce qui dilue le gain. La direction est fiable et le mécanisme est solide, mais un volume Btrfs sous charge mixte montrera une amélioration plus faible que le titre. Le gain sera maximal sur des petits blocs à l'intérieur de machines virtuelles.
Quand cela arrive t il, et y a t il quelque chose à faire ?
Les correctifs ont été publiés pour relecture le 26 août 2026 et n'étaient pas fusionnés au moment d'écrire ces lignes : aucun noyau publié ne les contient. Il n'y a aucun réglage à changer et rien à ajuster, le correctif étant entièrement interne, sans modification d'interface et sans action requise de qui exploite des systèmes de fichiers compressés en zstd. Le chemin réaliste est la relecture sur la liste, puis une fenêtre de fusion, puis l'arrivée dans une version stable, avec de bonnes chances de rétroportage vu le caractère autonome du changement. Surveillez les journaux de version du noyau plutôt que de planifier autour.