MGLRU-FG accélère la récupération mémoire de Linux jusqu’à 40 % dans les premiers tests
Les correctifs MGLRU-FG de Kairui Song ajoutent une promotion guidée par la fréquence d’accès au Multi-Gen LRU de Linux et gagnent de 10 à 40 % de performance selon la charge, avec une pointe à 76 % sous zRAM. Ils restent en RFC, mais les gains mesurés sur MongoDB, Chromium et la compilation du noyau justifient de suivre leur intégration de près.
Décembre 2022. Le Multi-Gen LRU (MGLRU) entre dans le noyau Linux 6.1 et change la façon dont Linux récupère les pages mémoire sous pression, avec des gains mesurables sur les serveurs comme sur Android. 3 octobre 2026. Le développeur Kairui Song publie la troisième version de ses correctifs MGLRU-FG, une « promotion guidée par la fréquence » qui s’ajoute au mécanisme d’éviction existant. 4 octobre 2026. Phoronix relaie les premiers chiffres : de 10 à 40 % de performance en plus selon la charge, et une pointe à 76 % sur un test Chromium et Node.js sous zRAM. Pourquoi c’est important : le reclaim mémoire est l’un des rares réglages du noyau qui profite à chaque processus d’une machine sans ajouter de matériel, et un gain à deux chiffres se traduit directement en latence, puis en coût cloud, pour une flotte entière.
Ce que MGLRU a déjà changé
Avant MGLRU, le reclaim de pages de Linux reposait sur deux listes — Active et Inactive — et une heuristique binaire : une page récemment accédée est « active », une page non accédée est « inactive » et finit par être évincée. Ce modèle fonctionne tant que le working set d’un processus tient en mémoire. Dès qu’il le dépasse, les pages chaudes et froides se mélangent dans les mêmes listes, le noyau évince des pages encore utilisées, et le système se met à thrasher : les refaults explosent et la latence se dégrade brutalement.
MGLRU, proposé par Yu Zhao et fusionné dans Linux 6.1, remplace ce couple de listes par une échelle de générations : une page promue ou accédée monte vers les générations jeunes, une page oubliée descend vers les générations anciennes, et l’éviction s’attaque d’abord aux plus anciennes. Le résultat est une décision d’éviction plus proche de la réalité du working set, et des gains déjà documentés sous pression mémoire sur les serveurs, les ordinateurs de bureau et les appareils mobiles.
Ce résultat a une portée rare. Le couple Active/Inactive est l’un des plus vieux mécanismes du noyau, et il n’avait presque jamais été remis en cause en profondeur avant MGLRU. L’échelle de générations classe les pages non pas sur une présence binaire dans une liste, mais sur une trajectoire : une page chaudement accédée reste jeune, une page oubliée vieillit progressivement. L’éviction devient une décision graduelle plutôt qu’un basculement brutal, ce qui réduit le risque d’évincer la mauvaise page au moment où un processus en a justement besoin.
Une promotion proactive au lieu d’une éviction réactive
MGLRU-FG pousse la logique un cran plus loin. Jusqu’ici, MGLRU protège ses niveaux au moment de l’éviction, via un contrôleur PID qui ajuste la vitesse à laquelle les pages descendent de génération en génération. Kairui Song propose d’y ajouter une promotion guidée par la fréquence d’accès : au lieu d’attendre qu’une page soit sur le point d’être évincée pour décider si elle mérite de rester, le noyau la promeut proactivement dès que son compteur d’accès franchit un seuil.
Le mécanisme repose sur un compteur de références stocké dans les folio flags. Chaque accès incrémente ce compteur, qui reste mappé sur des niveaux logarithmiques comme avant, mais avec des seuils formalisés : LRU_REFS_REFERENCED (1), LRU_REFS_WORKINGSET (2), LRU_REFS_PROTECTED (3) et LRU_REFS_MAX (7). Quand le compteur atteint un seuil, le folio est promu sans attendre l’intervention du contrôleur. Les indicateurs PG_workingset et PG_referenced deviennent les deux bits bas de ce compteur, les bits hauts étant fournis par LRU_REFS_MASK. Conséquence directe : le noyau économise un bit de page flags — précieux sur les architectures où ces bits sont rares — tout en rendant la comptabilité des références plus précise.
Les chiffres, charge par charge
C’est la partie qui intéresse un opérateur. Les mesures rapportées par Phoronix couvrent plusieurs architectures, des serveurs, des ordinateurs de bureau et Android, et Kairui Song résume ainsi l’ensemble : « 10 à 40 % de performance en plus, ou de refaults en moins, selon les tests ».
Le détail par charge est parlant. La compilation du noyau gagne environ une seconde, et près de dix secondes quand on la lance avec 96 jobs pour accentuer la pression mémoire. MongoDB progresse de 13,5 %. Le test Chromium et Node.js qui s’appuie sur zRAM comme swap affiche une amélioration de 76 %. FIO voit son débit monter jusqu’à 11 %. Ces chiffres ne sont pas uniformes — c’est précisément le point : le gain est le plus marqué là où le reclaim est le goulot d’étranglement, c’est-à-dire sur les charges qui débordent la mémoire physique ou qui dépendent d’un swap compressé.
La diversité des plateformes compte aussi. Song insiste sur la reproductibilité des résultats « sur plusieurs serveurs d’architectures différentes, des ordinateurs de bureau et Android ». On n’a donc pas affaire à un unique banc de test flatteur, mais à une tendance cohérente mesurée sur des cibles hétérogènes — ce qui renforce la crédibilité d’un correctif aussi central.
Pourquoi ça reste un RFC
Song maintient le statut RFC (request for comments), et c’est un choix assumé. Le patch modifie en profondeur le LRU, y compris la lecture des indicateurs Active/Inactive, ce qui en fait un changement à haut risque pour une infrastructure aussi centrale. Il note lui-même que la V3 est « plus affectée par l’over-reclaim des pages anonymes », mais qu’elle offre de meilleurs résultats globaux, et qu’il s’agit d’un problème « à corriger plus tard ou séparément ». Autrement dit : le code est « déjà très utilisable, stable et performant », mais personne ne l’a encore audité pour une fusion en mainline.
Concrètement, cela signifie que MGLRU-FG n’est pas dans Linux 7.3, dont la rc6 vient de sortir, et qu’il ne sera pas non plus disponible via une simple mise à jour de distribution dans les prochaines semaines. Le chemin passe par la linux-kernel mailing list (LKML), les retours des mainteneurs, puis une éventuelle fenêtre de fusion ultérieure.
Ce que ça change pour un opérateur
Rien à installer aujourd’hui, mais trois choses à surveiller. Premièrement, si vous exploitez des charges sensibles au reclaim — bases de données, serveurs de compilation, conteneurs serrés en mémoire, postes à swap zRAM — ces chiffres mesurent exactement le coût d’opportunité que vous subissez aujourd’hui. Deuxièmement, le gain d’un bit de page flags intéresse les noyaux embarqués et les architectures où les bits de drapeaux sont comptés, pas seulement les gros serveurs. Troisièmement, le statut RFC est une invitation à tester : les mainteneurs ont besoin de retours sur des charges réelles avant d’envisager la fusion.
Verdict
Si vous exploitez des charges mémoire-bornées — compilation lourde, MongoDB, ou des terminaux zRAM — notez le sujet et suivez le fil LKML de Kairui Song : c’est le genre de correctif dont le gain se répercute sans changer une seule ligne de votre configuration. Si votre parc tourne sur des noyaux de distribution stables, ne faites rien pour l’instant — le patch n’est pas fusionné, et le risque d’un changement aussi profond ne se justifie pas en production avant l’aval des mainteneurs. Si vous contribuez ou testez des noyaux de développement, votre retour sur des charges réelles est précisément ce qui manque pour transformer un RFC prometteur en fonctionnalité mainline. La direction est claire : le reclaim de Linux est en train de passer d’une éviction réactive à une promotion proactive, et MGLRU-FG en est la preuve la plus chiffrée à ce jour.