L'un des derniers lots de gestion mémoire fusionnés dans Linux 7.3 corrige un écart de comportement qui coûtait discrètement de la performance sur les machines à mémoire contrainte. Le LRU classique protège les pages de fichiers exécutables mappées, de sorte que le code chaud reste en mémoire et que le système ne s'épuise pas à le relire. MGLRU, l'implémentation de récupération plus récente, se montrait moins fiable sur ce point et libérait ces pages plus volontiers. Une série de Baolin Wang, chez Alibaba, promeut les folios exécutables mappés après leur premier usage : sur un test volontairement affamé en mémoire, le temps système d'une compilation de noyau à 32 tâches est passé de 9248 secondes à 7861 secondes.
The short answer
Une série de Baolin Wang, chez Alibaba, fusionnée dans l'un des derniers lots de gestion mémoire de la fenêtre Linux 7.3, fait promouvoir par MGLRU les folios exécutables mappés après leur premier usage. Le LRU classique protégeait déjà ces pages pour que le code chaud reste en mémoire au lieu d'être relu depuis le stockage sous pression, et MGLRU se montrait moins fiable. Sur un serveur Arm à 32 coeurs maintenu à une limite de comptabilité mémoire de 2 Go pendant une compilation de noyau à 32 tâches, le temps système est passé de 9248 secondes à 7861 secondes. Aucun réglage à poser.
Si vous avez déjà vu un conteneur sous limite mémoire serrée passer plus de temps dans le noyau que dans votre application, ce correctif vous concerne. Le mécanisme derrière ce symptôme est ennuyeux et précis, et Linux 7.3 en traite une partie.
Le comportement qui manquait
Le LRU classique considère les pages de fichiers exécutables mappées comme dignes de protection. Ce biais est délibéré. Ces pages contiennent le code que vos processus exécutent à l'instant : les évincer libère très peu de mémoire et garantit une relecture immédiate depuis le stockage, ce qui, sous pression durable, devient la boucle d'épuisement où la machine passe son temps à paginer du code au lieu de l'exécuter.
MGLRU, l'implémentation générationnelle plus récente, s'est montrée moins fiable sur cette protection. Les pages exécutables étaient récupérées plus volontiers que le chemin classique ne l'aurait permis, et l'écart apparaissait exactement là où on l'attend : sur les machines sans marge mémoire.
La série de Baolin Wang change cela en promouvant les folios exécutables mappés après leur premier usage, de sorte qu'ils sortent de portée du balayage immédiat de récupération au lieu d'être traités comme n'importe quelle page adossée à un fichier.
Le chiffre, et ce qu'il vaut
La mesure provient d'un montage volontairement hostile : un serveur Arm à 32 coeurs, la limite de comptabilité mémoire bloquée à 2 Go, et une compilation de noyau à 32 tâches à l'intérieur. Une machine configurée pour ne rien faire d'autre que se disputer la mémoire.
Le temps système passe de 9248 secondes à 7861 secondes, soit environ quinze pour cent de moins, sur la part de la charge qui n'était que surcoût noyau.
Lisez cela comme une démonstration du mécanisme, pas comme une prévision. Sur une machine disposant de marge, la récupération tourne à peine et ce changement ne fait presque rien. Les configurations qui le sentiront ressemblent au test : conteneurs à limites serrées, machines virtuelles surengagées, exécuteurs d'intégration continue dimensionnés sur un budget mémoire plutôt que sur la charge, et tout matériel acheté à une époque où la mémoire coûtait moins cher qu'aujourd'hui.
Le problème plus large que cela révèle
L'intéressant n'est pas le correctif, c'est la raison pour laquelle il a fallu l'écrire.
Le noyau embarque aujourd'hui deux algorithmes d'éviction distincts dans le même fichier. Au sommet de mai 2026 consacré au stockage, aux systèmes de fichiers, à la gestion mémoire et à BPF, Shakeel Butt a défendu l'idée que cela n'est pas tenable : mm/vmscan.c a dépassé huit mille lignes, dont une part importante de code propre à MGLRU qui duplique une logique déjà présente sur le chemin traditionnel, et chaque correctif, optimisation ou fonction doit être écrit deux fois ou ne touche que la moitié des utilisateurs. Lorenzo Stoakes a proposé de modulariser le code comme première étape vers un partage accru.
Cette série est un cas d'école de la dynamique décrite. Une protection dont le LRU classique disposait depuis des années a dû être rebâtie séparément pour MGLRU, et les machines sous MGLRU ont porté l'écart entre temps. La direction annoncée est l'unification plutôt que le choix d'un vainqueur, et ce correctif ne change pas ce plan : il rappelle simplement pourquoi il existe.
Quoi en faire
Rien, au sens où il n'y a aucun réglage à poser. Le comportement est interne à MGLRU et s'applique dès que vous exécutez un noyau qui le contient.
Quelque chose, au sens où il vaut la peine de savoir quel chemin de récupération vos machines empruntent réellement avant d'attribuer un comportement mémoire à l'un ou l'autre. Le contrôle à l'exécution est /sys/kernel/mm/lru_gen/enabled, où 0x0001 est l'interrupteur principal de MGLRU et les bits suivants gouvernent l'effacement des bits d'accès dans les entrées de table de pages terminales et non terminales. À la compilation, cela dépend de CONFIG_LRU_GEN et CONFIG_LRU_GEN_ENABLED.
Linux 7.3 est une version chargée pour la mémoire et le stockage en général, avec notamment une contention réduite sur les verrous zsmalloc et KSM, un chemin zstd noyau bien moins coûteux et la prise en charge DAX de la mémoire attachée au tissu via famfs. Si vous exploitez du contraint en mémoire, ce cycle mérite une lecture attentive plutôt qu'un saut jusqu'au prochain LTS.
Sources et pour aller plus loin
- Linux 7.3 MGLRU Change Helps Executable Code Stays In Memory, Improving Performance, Phoronix, 27 août 2026
- What is to be done about MGLRU?, Jonathan Corbet, LWN.net, 20 mai 2026
- Multi-Gen LRU, guide d'administration du noyau Linux
Questions fréquentes
Qu'est ce que MGLRU et comment savoir si je l'utilise ?
MGLRU est le LRU multigénérationnel, une implémentation plus récente de la récupération mémoire qui range les pages en générations plutôt que dans le schéma à deux listes, active et inactive, du LRU classique. Il doit être compilé avec CONFIG_LRU_GEN et peut être activé à la compilation avec CONFIG_LRU_GEN_ENABLED. À l'exécution, le contrôle se trouve dans /sys/kernel/mm/lru_gen/enabled, où 0x0001 est l'interrupteur principal et les bits suivants pilotent l'effacement des bits d'accès dans les entrées de table de pages terminales et non terminales. Lire ce fichier est le moyen le plus rapide de trancher sur une machine en service, et cela vaut la peine avant d'attribuer un comportement de récupération à l'une ou l'autre implémentation.
Pourquoi les pages exécutables méritent elles un traitement particulier ?
Parce que les évincer coûte anormalement cher au regard du peu de mémoire ainsi libérée. Les pages de fichiers exécutables mappées contiennent le code que vos processus exécutent à l'instant même. Si la récupération les prend, la prochaine lecture d'instruction doit les relire depuis le stockage, et sous pression soutenue ce schéma se répète : c'est la boucle d'épuisement classique où la machine passe son temps à faire entrer et sortir du code plutôt qu'à travailler. Le LRU classique évite depuis longtemps de récupérer ces pages, précisément pour cette raison. Le correctif n'invente donc rien : il aligne MGLRU sur une protection que l'implémentation plus ancienne possédait déjà.
Que vaut le résultat de 9248 à 7861 secondes en pratique ?
Voyez y une démonstration du mécanisme plutôt qu'un chiffre à attendre. Baolin Wang l'a obtenu sur un serveur Arm à 32 coeurs, la limite de comptabilité mémoire fixée à 2 Go, avec une compilation de noyau à 32 tâches, soit un montage volontairement extrême conçu pour maintenir la machine en manque permanent de mémoire. La baisse de 9248 à 7861 secondes de temps système représente environ quinze pour cent, et elle est réelle, mais une machine disposant de marge ne verra presque rien puisque la récupération tourne à peine. Les configurations qui le sentiront ressemblent au test : conteneurs à limites serrées, machines virtuelles surengagées, fermes de compilation dimensionnées sur le budget mémoire plutôt que sur la charge.
Faut il en conclure que MGLRU était une erreur ?
Non, mais cela illustre un coût réel dont les développeurs du noyau discutent ouvertement. Au sommet 2026 consacré au stockage, aux systèmes de fichiers, à la gestion mémoire et à BPF, Shakeel Butt a soutenu que livrer deux algorithmes d'éviction distincts dans le même fichier n'est pas tenable, mm/vmscan.c ayant dépassé huit mille lignes avec une part importante propre à MGLRU, si bien que chaque correctif doit être écrit deux fois ou ne touche que la moitié des utilisateurs. Cette série illustre parfaitement cette dynamique : une protection présente sur un chemin a dû être réimplémentée sur l'autre. Un travail d'unification des deux est engagé, plutôt qu'un choix d'un vainqueur.
Faut il modifier une configuration pour en bénéficier ?
Non. C'est un changement de comportement interne à MGLRU : il s'applique automatiquement dès que vous exécutez un noyau qui le contient et que MGLRU est l'implémentation de récupération active sur votre système. Il n'y a pas de nouveau réglage, et rien à activer. La seule décision qui vaille est de savoir si MGLRU est le bon choix sur une machine donnée, question que ce correctif ne change pas, sinon en supprimant une raison précise de répondre non.