Linux 7.3 abat jusqu’à 500 fois la contention de verrous en gestion mémoire
Deux optimisations fusionnées dans la fenêtre de merge de Linux 7.3 réduisent la contention de verrous en gestion mémoire : le pire temps de maintien d’un verrou anon_vma passe de 705 ms à 1,67 ms, et le chemin zsmalloc accélère jusqu’à 1,83 fois sur matériel modeste. Les équipes qui font tourner des JVM, des bases de données ou du KSM sous pression mémoire ont un gain de latence direct à l’upgrade.
19 août 2026. Andrew Morton envoie les mises à jour de gestion mémoire (MM) pour la fenêtre de merge de Linux 7.3 : 1 250 patchs, contre 920 au cycle précédent. 6 septembre 2026. Linux 7.3-rc2 est publié, et la série avance vers une sortie stable. Deux optimisations enfouies dans ce flot de patchs changent concrètement la vie des serveurs sous pression mémoire : l’une abat le pire temps de maintien d’un verrou de 705 ms à 1,67 ms, l’autre accélère le chemin zsmalloc jusqu’à 1,83 fois. Pour un SRE, c’est le genre de gain qui ne demande aucun changement de configuration — juste un noyau.
Un verrou tenu 705 millisecondes, ramené à 1,67
La première optimisation concerne rmap_walk_ksm(), la fonction qui parcourt la cartographie inverse des pages gérées par KSM (Kernel Samepage Merging). Le problème, découvert par les ingénieurs de ZTE, était « sévère » : quand un grand nombre de VMA sans rapport partagent un même anon_vma, le parcours inverse tient le verrou anon_vma pendant des centaines de millisecondes sous pression mémoire.
Le chiffre exact est saisissant. Dans un benchmark reproduisant 20 000 VMA partageant un seul anon_vma, le pire temps de maintien du verrou passe de 705 ms à 1,67 ms en valeur maximale, et à 1,44 ms en moyenne. Soit une réduction de 100 à 500 fois.
Pourquoi cela compte au-delà du micro-benchmark ? Parce que le verrou anon_vma n’est pas réservé à KSM. Il est aussi acquis par les fautes de pages, la réclamation mémoire, la migration, la compaction, mlock, exit_mmap et la comptabilité cgroup. Un maintien long dû à un parcours inverse inefficace bloque les threads applicatifs : pics de latence, baisse de débit, et parfois des timeouts de conteneurs.
Xu Xin, l’ingénieur ZTE à l’origine du correctif, donne des exemples concrets de production. Les runtimes JVM et Go utilisent mmap pour leurs régions de tas puis appellent mprotect(PROT_NONE) pour les barrières de collecte ou les pages de garde, découpant le VMA d’origine en milliers de fragments au fil du temps. Les moteurs de base de données comme MySQL et PostgreSQL font de même avec madvise(MADV_DONTNEED). Résultat : des dizaines de milliers de VMA accrochées au même anon_vma sur des machines qui ne font rien d’exotique.
Le chemin zsmalloc accéléré, même sur un Raspberry Pi
La seconde optimisation réduit la contention de verrou dans zs_free(), la fonction de libération de l’allocateur zsmalloc, utilisée par zswap et zRAM pour relâcher des pages compressées. Cette contention se manifeste surtout dans le chemin de désallocation quand le système est sous pression mémoire — typiquement sur les appareils Android de Google ou les serveurs aux charges zswap importantes.
Le benchmark parle de lui-même. Wenchao Hao, de Xiaomi, a mesuré l’opération « mapper 256 Mo, écrire, madvise pour paginer vers zRAM, puis désallouer en concurrence » : un Intel 20 cœurs gagne jusqu’à 1,4 fois, et un modeste Raspberry Pi 4B jusqu’à 1,83 fois. Que le gain le plus net soit sur le plus petit matériel n’est pas un hasard — c’est là que la contention de verrou pèse proportionnellement le plus.
Pour les serveurs, l’enjeu est lié au prix de la mémoire. Avec la flambée récente du coût de la DDR5, zswap et zRAM deviennent des leviers économiques de premier ordre : compresser une partie de la mémoire vive coûte moins cher qu’acheter des barrettes. Une contention réduite dans zsmalloc rend ce compromis moins pénalisant en latence, et donc plus défendable.
Un flot de patchs que l’IA a aidé à résumer
Le contexte mérite une parenthèse. Andrew Morton a explicitement noté que les 1 250 courriels « added-to-MM » de ce cycle représentaient une hausse de 36 % par rapport aux 920 du cycle précédent, et qu’il s’était tourné vers l’IA Gemini de Google pour rédiger ses résumés de patchs. C’est un signal de fond : le volume de contribution au noyau dépasse ce qu’un mainteneur humain peut résumer à la main.
La nouvelle est bonne pour la gestion mémoire de Linux 7.3, mais elle l’est aussi pour la lisibilité du processus. Quand un mainteneur délègue la synthèse à un modèle, la qualité du résumé dépend de la qualité du prompt — et le fait que Morton ait su extraire deux optimisations majeures d’un flot de 1 250 patchs montre que l’outil a servi, pas remplacé, le jugement humain.
Ce qu’il faut retenir pour vos serveurs
Le point décisif est que ces gains ne demandent aucune configuration. Ni KSM ni zswap ne nécessitent de nouveau réglage : les optimisations agissent dans le noyau, sur des chemins déjà empruntés par les charges qui les subissent. L’upgrade suffit.
Vérifiez simplement si vos charges sont concernées. Un système qui active KSM s’inspecte en une commande :
cat /sys/kernel/mm/ksm/run # 1 = KSM activé, 0 = désactivé
cat /sys/kernel/mm/ksm/pages_shared # pages réellement fusionnéesSi KSM est actif sur une machine qui héberge des JVM, des runtimes Go ou des bases de données, vous êtes dans la population cible de l’optimisation rmap_walk_ksm. Si vous utilisez zswap ou zRAM pour tenir des charges sous pression mémoire, vous profitez du correctif zs_free.
Verdict
Linux 7.3 n’est pas qu’un énième cycle de noyau : ses optimisations de gestion mémoire s’attaquent à une classe de latence que les équipes d’exploitation subissent sans pouvoir la diagnostiquer — la contention de verrou qui fige des threads pendant des centaines de millisecondes. Les chiffres de ZTE et de Xiaomi transforment un problème invisible en un gain mesurable.
Si vous exploitez des JVM, des runtimes Go ou des bases de données sous pression mémoire, avec KSM activé, planifiez le passage à Linux 7.3 dès sa sortie stable et mesurez la latence de queue avant et après : la réduction du temps de maintien de verrou se lit directement sur les percentiles hauts.
Si vous utilisez zswap ou zRAM pour contenir vos coûts mémoire, le correctif zs_free rend le compromis compression/latence plus favorable — un argument de plus pour rester à jour plutôt que de geler un noyau « qui fonctionne ».
Si vos charges n’activent ni KSM ni zswap, vous ne verrez probablement rien : ces correctifs sont chirurgicaux, et c’est précisément leur qualité. Mettez à jour pour la sécurité et les autres correctifs, sans attendre de miracle de latence.