Deux changements de gestion mémoire fusionnés pour Linux 7.3 attaquent le même problème par deux bouts : un verrou tenu beaucoup trop longtemps alors que la machine souffre déjà. Le premier réduit la contention dans zs_free, le chemin de libération de l'allocateur zsmalloc sur lequel reposent zRAM et Zswap, mesuré jusqu'à 1,83 fois plus rapide sur un Raspberry Pi 4B et jusqu'à 1,4 fois sur une machine Intel à vingt coeurs. Le second réécrit le parcours de correspondance inverse utilisé par Kernel Samepage Merging, faisant passer un pire cas de 705 millisecondes à 1,67 milliseconde. Rapporté le mercredi 19 août 2026.
The short answer
Andrew Morton a envoyé les mises à jour de gestion mémoire pour la fenêtre de fusion de Linux 7.3, rapportées le mercredi 19 août 2026. La contention de verrou réduite dans le chemin zs_free de zsmalloc, dont dépendent zRAM et Zswap, est mesurée jusqu'à 1,83 fois plus rapide sur un Raspberry Pi 4B et jusqu'à 1,4 fois sur un système Intel à vingt coeurs. Séparément, des ingénieurs de ZTE ont réécrit rmap_walk_ksm : les durées de maintien de verrou passent de plus de 500 millisecondes à moins de 2 millisecondes.
Un verrou tenu 705 millisecondes n'est pas un problème de performance. C'est une interruption de service que personne n'a journalisée, parce que vue depuis l'espace utilisateur la machine s'est simplement arrêtée deux tiers de seconde avant de repartir.
Les deux changements
Andrew Morton a envoyé les demandes de fusion de gestion mémoire pour la fenêtre de Linux 7.3, et le compte rendu est paru le mercredi 19 août 2026. Deux éléments méritent une lecture attentive si vous exploitez quoi que ce soit de contraint en mémoire.
Le premier réduit la contention de verrou dans zs_free. Cette fonction appartient à zsmalloc, l'allocateur spécialisé que le noyau utilise pour ranger efficacement les pages compressées, et zsmalloc est ce sur quoi reposent zRAM et Zswap. La contention est décrite comme significative dans le chemin de démappage quand le système est sous pression mémoire, avec les appareils Android de Google et les serveurs aux charges très orientées Zswap cités comme cas concernés.
Le second vise rmap_walk_ksm, le parcours de correspondance inverse pour les pages gérées par Kernel Samepage Merging. Des ingénieurs de ZTE, avec Xu Xin à la manoeuvre, ont décrit le comportement existant comme un problème de performance grave où les applications peuvent geler pendant des centaines de millisecondes sous pression mémoire.
Sous systèmes différents, mode de défaillance identique. Dans les deux cas le noyau prend un verrou, effectue un travail dont la durée croît avec la charge de la machine, et immobilise tout le monde pendant qu'il termine.
zsmalloc, et pourquoi le chiffre du Raspberry Pi est le plus parlant
Le test de Wenchao Hao, de Xiaomi, est assez simple à se représenter. Des processus mappent 256 Mo, y écrivent des données, appellent madvise pour pousser ces pages vers zRAM, puis démappent en parallèle. Le démappage concurrent constitue la pression : plusieurs processeurs arrivent dans zs_free au même instant et font la queue les uns derrière les autres.
Sur un Raspberry Pi 4B, le correctif vaut jusqu'à 1,83 fois plus vite. Sur un système Intel à vingt coeurs, jusqu'à 1,4 fois.
Lisez ces deux chiffres ensemble plutôt que de retenir le plus gros. La petite carte ARM gagne davantage, et c'est exactement ce qu'on attend d'une correction de contention de verrou, parce que des coeurs plus lents passent proportionnellement plus de temps dans la section critique et disposent de moins de marge pour absorber l'attente. La machine à vingt coeurs a plus de processeurs en concurrence mais chacun libère le verrou plus vite.
La traduction pratique, c'est que ce changement aide le plus le matériel le moins capable de se défendre. Noeuds de périphérie, petites machines ARM, machines virtuelles serrées en mémoire, tout ce qui utilise zRAM comme moyen de survivre avec moins de mémoire vive que la charge n'en voudrait. Ce sont les machines où un chemin de libération lent s'aggrave, puisque la raison même d'activer zRAM est de tourner près de la limite.
KSM, et le blocage qui a poussé certains à le couper
Kernel Samepage Merging repère les pages identiques en mémoire et les rassemble en une seule page physique partagée par de nombreuses correspondances. Sur un hôte KVM qui fait tourner des dizaines d'invités issus de la même image de base, l'économie est substantielle, et c'est pour cela que KSM existe et que les exploitants d'hyperviseurs y reviennent.
Le partage a un coût, et ce coût se paie dans le sens inverse. Une fois une page partagée, le noyau doit parfois retrouver chaque correspondance qui pointe dessus, et rmap_walk_ksm est la fonction qui effectue ce parcours. Plus vous avez obtenu de partage, plus le parcours est long.
Les mesures de ZTE rendent la pathologie concrète. Dans le pire cas construit, 20 000 zones mémoire virtuelles partageaient un unique anon_vma. La durée de maintien du verrou atteignait alors 705 millisecondes au maximum. Après optimisation, le même cas mesure 1,67 milliseconde au maximum et 1,44 milliseconde en moyenne. Formulé plus généralement, les durées de maintien passent de plus de 500 millisecondes à moins de 2 millisecondes.
Cela représente un facteur d'environ quatre cents, et c'est le rare chiffre noyau où le multiplicateur sous estime l'effet. Une demi seconde de gestion mémoire figée ne dégrade pas une charge en douceur. Elle fait expirer un contrôle de santé, elle déclenche une élection de leader, elle fait passer un réplica de base de données pour mort auprès de ses pairs. Les conséquences sont des pannes distinctes plutôt qu'un centile légèrement moins bon.
Il y a là une note d'exploitation. Si vous avez déjà désactivé KSM sur un hyperviseur parce que des invités gelaient pour des raisons que personne n'arrivait à cerner, voilà une explication plausible de ce que vous observiez, et le compromis qui vous avait fait couper la fonction a changé. Cela vaut la peine de remesurer sur 7.3 plutôt que de considérer votre ancienne décision comme acquise.
Où cela se situe dans le cycle 7.3
Linux 7.3 devient un cycle chargé pour les parties du noyau qui décident qui attend et combien de temps. Le volet ordonnanceur de la même fenêtre a apporté une refonte de l'ordonnancement cgroup qui place EEVDF sur une file unique, qui attaque la gigue des charges conteneurisées par le processeur pendant que ces deux correctifs l'attaquent par la mémoire.
La base de tout cela est Linux 7.2, sorti à la mi août 2026, la 7.3 est donc au début de son cycle et une version stable se situe à environ deux mois au rythme habituel.
Aucun des deux changements mémoire ne demande de configuration. Pas de nouveau réglage, pas de nouveau sysctl, aucun comportement à activer. La mise à jour constitue toute l'action, ce qui est la meilleure sorte de correctif noyau, et aussi celle dont personne ne crédite l'auteur quand les blocages cessent.
Ce qu'il faut mesurer avant la mise à jour
Si vous exploitez zRAM ou Zswap, relevez dès maintenant à quoi ressemble le démappage sous pression. Une version simple consiste à observer le temps de sortie d'un processus gourmand en mémoire pendant que la machine échange vers zRAM, puisque la destruction est le moment où le chemin de libération est le plus sollicité.
Si vous exploitez KSM sur un hyperviseur, cherchez les blocages plutôt que le débit. Les sauts d'horloge côté invité, les contrôles de santé qui expirent en grappe sans cause évidente et les pics de cent millisecondes dans des courbes de latence par ailleurs plates sont les empreintes à repérer. Un pire cas qui passe de 705 millisecondes à moins de 2 apparaîtra dans la queue de ces courbes et nulle part ailleurs.
Les deux valent la peine d'être notés avant la mise à jour plutôt qu'après, parce qu'une correction de cette ampleur est invisible dans une moyenne et évidente dans un maximum, et personne ne conserve des maximums par hasard.
Sources et pour aller plus loin
- Two Very Exciting Memory Management Optimizations Going Into Linux 7.3, Phoronix, 19 août 2026
- zsmalloc, documentation du noyau Linux
- Kernel Samepage Merging, documentation du noyau Linux
- Linux 7.2 Released With Faster I/O, New AMD and Intel Driver Improvements, Phoronix, août 2026
Questions fréquentes
Quelles charges passent réellement par zsmalloc ?
Tout ce qui utilise zRAM ou Zswap, ce qui représente un parc plus large qu'on ne l'imagine. zsmalloc est l'allocateur qui range les pages compressées, et zs_free est ce qui s'exécute quand ces pages compressées sont libérées. La contention apparaît dans le chemin de démappage quand la machine est déjà sous pression mémoire, la forme du problème est donc une machine à court de mémoire vive qui ralentit précisément pendant qu'elle tente de récupérer. Deux cas sont nommés : les appareils Android, où zRAM est standard, et les serveurs aux charges très orientées Zswap. Les hôtes de conteneurs qui s'appuient sur zRAM plutôt que sur un fichier d'échange disque tombent dans la seconde catégorie.
Que mesure le test, et sur quel matériel ?
Le test fait mapper 256 Mo par des processus, écrire des données dedans, appeler madvise pour pousser les pages vers zRAM, puis démapper en parallèle. Ce démappage concurrent final est ce qui frappe zs_free depuis plusieurs processeurs à la fois. Sur un Raspberry Pi 4B, le changement vaut jusqu'à 1,83 fois plus vite. Sur un système Intel à vingt coeurs, jusqu'à 1,4 fois. L'écart entre ces deux chiffres est instructif : une petite carte ARM aux coeurs lents ressent la contention de verrou bien plus durement qu'un serveur large, ce qui est un rappel utile si votre parc comprend du matériel de périphérie.
Qu'est ce que KSM et pourquoi bloquait il 705 millisecondes ?
Kernel Samepage Merging déduplique les pages mémoire identiques, raison pour laquelle il est courant sur les hôtes KVM qui font tourner beaucoup d'invités semblables. Fusionner signifie qu'une page physique est désormais référencée depuis de nombreux endroits, et rmap_walk_ksm est la fonction qui remonte ces références quand le noyau doit agir sur la page. Des ingénieurs de ZTE ont trouvé ce parcours tenant un verrou très longtemps dans le cas pathologique : 20 000 zones mémoire virtuelles partageant un seul anon_vma. Le pire cas rapporté était de 705 millisecondes de maintien de verrou. Vu depuis l'invité, cela ressemble à une machine entière figée pendant deux tiers de seconde.
Faut il activer quelque chose pour bénéficier de ces correctifs ?
Non. Les deux changements se situent dans des chemins de code existants, passer à Linux 7.3 constitue donc toute l'action à mener. Aucun des deux n'introduit de nouveau réglage, et aucun ne modifie le comportement au point d'exiger une révision de votre configuration zRAM ou KSM. Ce qui mérite en revanche un examen, c'est de savoir si vous avez désactivé KSM à un moment donné à cause exactement de ce symptôme. Beaucoup d'exploitants KVM ont coupé la fusion de pages après avoir traqué des gels d'invités inexpliqués, et le calcul qui faisait de KSM un mauvais compromis peut désormais tomber autrement sur des hôtes aux invités similaires.
Quand Linux 7.3 sortira t il réellement ?
La fenêtre de fusion de la 7.3 s'est ouverte peu après la sortie de Linux 7.2 à la mi août 2026, et un cycle noyau dure généralement environ deux mois entre la fenêtre de fusion et la version stable. Cela situe une sortie de la 7.3 dans la seconde moitié d'octobre 2026 au rythme habituel, avec des versions candidates hebdomadaires d'ici là. Les distributions qui suivent la branche principale de près l'auront plus tôt que les distributions d'entreprise, ce qui est la répartition normale. Si l'un de ces correctifs concerne un symptôme de production que vous traquez aujourd'hui, les versions candidates sont l'endroit le plus tôt raisonnable pour tester, pas pour exploiter.