Linux 7.4 accélère jusqu’à 81 % l’ajout de mémoire à chaud sur les VM et le CXL
Une série de correctifs signée Yuan Liu (Intel), en file dans mm/core.git pour la fenêtre de fusion de Linux 7.4, remplace le balayage page par page des zones par une vérification de contiguïté optimisée. Mesuré : jusqu’à 81 % de réduction du temps d’ajout de mémoire à chaud sur une VM et 75 % sur le retrait, avec des gains aussi constatés par Samsung sur CXL.
27 septembre 2026. Michael Larabel documente sur Phoronix une optimisation du hotplug mémoire préparée pour Linux 7.4. 27 septembre 2026. Yuan Liu, ingénieur chez Intel, mène la réécriture des vérifications de contiguïté de zone qui ralentissaient l’ajout de RAM. Octobre 2026. C’est la fenêtre de fusion de Linux 7.4, où la série de correctifs, déjà en file dans mm/core.git, est attendue. Pourquoi c’est important : ajouter de la mémoire à chaud — sur une machine virtuelle ou via CXL — devient jusqu’à 81 % plus rapide, un gain qui touche directement l’élasticité du cloud.
Ajouter de la mémoire sans redémarrer
Le hotplug mémoire est la capacité du noyau à intégrer de la RAM supplémentaire pendant que le système tourne, sans redémarrage. Deux cas d’usage le rendent stratégique. Le premier est la virtualisation : QEMU et KVM savent agrandir la mémoire d’une machine virtuelle à chaud, et c’est ce mécanisme que les fournisseurs de cloud utilisent pour faire passer un serveur d’un gabarit à un autre sans l’éteindre. Le second est le CXL (Compute Express Link), qui permet d’attacher des modules d’extension mémoire — voire de composer de la mémoire entre machines — comme on brancherait un périphérique.
Dans les deux cas, le chemin noyau est le même. Le système doit découvrir de nouvelles plages physiques, les découper en page blocks, vérifier qu’elles sont utilisables, puis les mettre en ligne dans l’allocateur. C’est précisément dans cette séquence de mise en ligne que se cachait le goulot d’étranglement.
Le goulot : vérifier la contiguïté d’une zone, page par page
Avant de mettre une plage en ligne, le noyau doit s’assurer de la contiguïté de la mémoire concernée. Une zone mémoire est organisée en page blocks — des unités de plusieurs pages — et l’ajout à chaud suppose de déterminer quelles portions sont réellement contiguës et libres. La méthode historique procédait par balayage page-block par page-block à travers toute la zone, une opération dont le coût grandit avec la taille de la zone, pas avec la quantité de mémoire ajoutée.
Conséquence : ajouter un peu de mémoire à une grande zone coûtait cher, parce que la vérification passait en revue l’ensemble de la zone plutôt que la seule plage concernée. C’est exactement le genre de coût qu’on ne remarque pas tant que les machines sont petites, mais qui devient mesurable dès que les zones atteignent les centaines de gigaoctets — le cas typique des hôtes de virtualisation et des infrastructures CXL.
Ce que change la série de Yuan Liu
La série de correctifs menée par Yuan Liu s’attaque à ces vérifications de contiguïté de zone. Son objet, tel que décrit dans la lettre de couverture : optimiser ces contrôles pour éviter les balayages page-block par page-block à travers une zone entière. Concrètement, le travail évite de parcourir l’intégralité de la zone quand seule une portion est ajoutée, et recentre la vérification sur ce qui est nécessaire à la mise en ligne de la nouvelle plage.
Les correctifs sont déjà en file dans la branche for-next de mm/core.git — le dépôt où atterrissent les changements de gestion mémoire avant la fenêtre de fusion. Le commit de référence porte l’identifiant fa4df92e3d18e2428d7313350350de21824e183d, et son arrivée dans la branche for-next signifie qu’il est attendu pour la fusion dans Linux 7.4, dont la fenêtre ouvre en octobre.
Les chiffres : jusqu’à 81 % sur une VM, et des gains CXL
Les mesures publiées avec la série sont à la hauteur du problème. Sur une machine virtuelle, l’ajout de mémoire à chaud voit son temps réduit de 81 %, et le retrait à chaud de 75 %. Ce sont les deux directions de l’élasticité — grandir et rétrécir — qui bénéficient du gain, ce qui importe pour les plateformes qui font du right-sizing automatique.
Samsung a mené des tests complémentaires sur le CXL et constate des améliorations « substantielles » du hotplug de mémoire via CXL, selon Phoronix. C’est le second cas d’usage stratégique qui se trouve accéléré : attacher de la mémoire extension à une machine devient moins coûteux, ce qui rapproche le CXL d’un usage en production routinier.
Pourquoi cela compte en production
Le hotplug mémoire est un coût fixe de l’élasticité. À chaque changement de gabarit d’une VM, à chaque attache d’un module CXL, le noyau paie le prix de la vérification de contiguïté. Réduire ce prix de 81 % ne change pas une seule application, mais accélère les opérations d’infrastructure qui, elles, se répètent des milliers de fois par jour dans un datacenter.
Pour les équipes qui gèrent du KVM ou du CXL, ce changement arrivera avec Linux 7.4, donc dans les distributions à venir — pas dans les noyaux stables actuels, dont Ubuntu 26.10 embarque Linux 7.3. Vérifier que le hotplug mémoire est bien activé sur une machine ne demande que deux commandes :
grep -E 'CONFIG_MEMORY_HOTPLUG' /boot/config-$(uname -r)
ls /sys/devices/system/memory/CXL : la mémoire qui se branche comme un périphérique
Le CXL change la nature de la mémoire. Là où la RAM d’un serveur était une ressource fixe, soudée à la carte mère et dimensionnée une fois pour toutes, le CXL en fait une ressource composable : des modules d’extension mémoire se branchent sur un connecteur et exposent leurs plages au processeur comme de la mémoire système. Le hotplug devient alors l’opération quotidienne — attacher, détacher, redimensionner — et non l’exception qu’on réserve aux fenêtres de maintenance.
C’est pourquoi le gain mesuré par Samsung sur CXL compte autant que celui des machines virtuelles. Attacher un module CXL suppose de passer par le même chemin de mise en ligne que l’ajout de RAM à une VM : découverte des plages, découpage en page blocks, vérification de contiguïté, puis mise en ligne. Si cette vérification balaie la zone entière, le coût d’attache grandit avec la taille de la zone déjà en ligne — précisément ce qui rendrait le CXL peu attractif au-delà des démonstrations. La série de Yuan Liu lève ce frein.
À terme, l’enjeu dépasse le simple gain de vitesse. Une mémoire qu’on attache et détache à chaud, sans pénalité, c’est la brique qui manquait à la composabilité : allouer de la mémoire à la demande entre machines, en fonction de la charge, au lieu de la surprovisionner partout. Le hotplug rapide n’est donc pas qu’une optimisation de confort — c’est une condition de l’architecture mémoire de la prochaine décennie.
Verdict
Si vous exploitez des hôtes de virtualisation ou du CXL, retenez cette série comme un gain d’infrastructure à coût nul — aucun changement d’interface, aucune configuration à adapter, un bénéfice mesuré sur les deux directions de l’élasticité. Si vous suivez les noyaux de développement, testez le correctif sur vos propres séquences d’ajout et de retrait de mémoire : les gains de 81 % et 75 % sont des ordres de grandeur, vos charges préciseront la réalité. Si vous n’êtes pas concerné par le CXL ou la virtualisation à chaud, l’enseignement est ailleurs : la performance du noyau se joue de plus en plus dans la gestion mémoire fine, et un balayage page par page qu’on croyait anodin devient, à l’échelle des zones modernes, le goulot qu’on ne cherchait pas. L’élasticité du cloud s’accélère d’une rustine — c’est le genre de correctif qui ne fait pas la une, mais qui rend tout le reste plus fluide.