Reproduire un bug de pression mémoire consiste d'ordinaire à remplir la RAM en espérant que le noyau emprunte le chemin qui vous intéresse. Une demande de commentaires signée Juan Yescas, de Google, publiée le 6 août 2026, propose un instrument plus précis. Page Alloc Hogger expose une interface DebugFS qui alloue des pages depuis un noeud NUMA, une zone, un type de migration et un ordre d'allocation donnés, ce qui permet de viser une partie de l'allocateur plutôt que la machine entière. L'objectif annoncé est de déclencher et d'observer la récupération directe, kswapd, le tueur OOM et les replis d'allocation sans écrire un pilote sur mesure. C'est une aide au débogage, pas une fonction de production.
The short answer
Juan Yescas, de Google, a publié le 6 août 2026 une demande de commentaires proposant Page Alloc Hogger, une interface DebugFS qui alloue des pages mémoire depuis un noeud, une zone, un type de migration et un ordre choisis. Le but est la précision : au lieu de remplir la mémoire en espérant que le noyau emprunte le chemin voulu, vous visez un coin de l'allocateur. Il s'agit de déclencher à la demande la récupération directe, kswapd, le tueur OOM et les replis d'allocation. Explicitement une aide au test et au débogage, pas quelque chose à faire tourner en production.
Quiconque a poursuivi un bug qui n'apparaît que lorsqu'une machine manque de mémoire connaît la forme du problème. Le bug est réel, le rapport est crédible, et les conditions refusent de revenir à la demande. Vous allouez jusqu'à ce que quelque chose cède, le noyau récupère de la mémoire ailleurs, et le chemin que vous vouliez réellement exercer ne s'exécute jamais.
Une série de correctifs publiée le 6 août par Juan Yescas, de Google, propose un instrument plus précis pour ce travail. Page Alloc Hogger ajoute une interface DebugFS qui alloue des pages avec les paramètres de l'allocateur explicités, ce qui transforme un test de charge grossier en quelque chose de proche d'une reproduction.
Une pression que l'on peut viser
L'allocateur de pages ne traite pas la mémoire comme un réservoir unique, et si les bugs sont difficiles à reproduire, c'est justement parce que ces distinctions comptent.
Une demande porte un noeud NUMA, qui sur une machine multi socket détermine à quel processeur la mémoire est rattachée. Elle porte une zone, subdivision qui existe parce que certains matériels ne peuvent adresser qu'une partie de l'espace, raison pour laquelle DMA, DMA32 et Normal restent séparées. Elle porte un type de migration, le regroupement des pages par déplaçabilité, principale défense contre la fragmentation. Et elle porte un ordre, la taille en puissance de deux pages, où l'ordre zéro vaut une page et l'ordre neuf deux mégaoctets.
Un programme en espace utilisateur qui alloue en boucle ne choisit aucun de ces quatre paramètres. Page Alloc Hogger les prend tous.
Pourquoi l'outil doit être dans le noyau
Il y a une raison pratique pour que ce ne soit pas un utilitaire en espace utilisateur, et elle passe facilement inaperçue.
Si l'élément qui applique la pression mémoire est un processus ordinaire, il est aussi un candidat pour le tueur OOM. Souvent le meilleur candidat, puisqu'il est de loin le plus gros consommateur de la machine. L'expérience se termine donc en tuant l'outil qui la mène, exactement au moment où le comportement étudié commence. Allouer depuis le contexte noyau supprime ce travers, et la pression demeure jusqu'à ce que vous la relâchiez.
Les comportements qu'il expose
Le noyau possède un ensemble de mécanismes qui ne s'exécutent que lorsque la mémoire manque, et ils sont difficiles à étudier pour la même raison qui les rend importants.
La récupération directe est celui qui se cache le plus probablement derrière une plainte que vous avez reçue. Quand une allocation ne peut être satisfaite, la tâche demandeuse va libérer de la mémoire elle même avant de poursuivre. L'application ne voit pas une erreur, elle voit une pause, d'où le fait que cela arrive sous forme de rapport de latence plutôt que de rapport mémoire. Kswapd en est la version d'arrière plan, récupérant en avance de la demande, et l'écart entre les deux est le terrain d'une bonne partie du réglage fin.
Le tueur OOM est le bout de la chaîne, et ses décisions alimentent des débats récurrents. Les replis d'allocation sont plus discrets : quand la zone ou le type de migration préféré ne peut satisfaire une demande, l'allocateur prend de la mémoire ailleurs, et des replis répétés sont la façon dont la fragmentation devient un ralentissement mesurable.
Yescas présente la valeur de l'outil comme la capacité à déclencher et inspecter précisément ces mécanismes, plus le test unitaire du code de gestion mémoire et l'évaluation du comportement applicatif sous forte contrainte.
Ce que ce n'est pas
Ce n'est pas un outil de production, et la RFC le dit sans détour. Cela vit dans DebugFS, que quantité de systèmes durcis ne montent pas, et sa fonction est de consommer de la mémoire dont rien ne se servira.
Ce n'est pas non plus fusionné. Il s'agit d'une demande de commentaires, le stade formel le plus précoce d'une proposition noyau, et l'étiquette signifie un retour sur la conception plutôt qu'une relecture d'un travail fini. Une part significative des séries RFC changent de forme ou n'atterrissent jamais, et la gestion mémoire attire plus d'examen que la plupart des sous systèmes parce que le coût d'une erreur y est élevé. Il n'y a pas de version cible.
Ce que nous en ferions
Si vous écrivez du code noyau qui touche à l'allocation, l'outil est directement utile et la liste de diffusion est l'endroit où le dire tant que l'interface peut encore bouger.
Sinon, le public intéressant est plus étroit qu'il n'y paraît mais bien réel : les personnes dont le budget mémoire est fixe et serré. L'embarqué et le mobile vivent là en permanence, tout comme quiconque dimensionne des conteneurs contre des limites plutôt que contre la RAM disponible. Pouvoir placer une machine dans un état de mémoire basse précis et l'y maintenir est un meilleur test que remplir la mémoire en regardant ce qui se passe, parce que le second teste une condition que vous ne saurez pas décrire après coup.
Pour tous les autres, cela vaut d'être classé plutôt que d'être appliqué. C'est précoce, l'interface bougera vraisemblablement, et la valeur arrivera quand la fonction atterrira dans un noyau que vous utilisez déjà.
Sources et pour aller plus loin
- Page Alloc Hogger permet de mieux stresser le comportement mémoire de Linux pour le test et le débogage, Phoronix, 6 août 2026
- La série de correctifs RFC Page Alloc Hogger, Juan Yescas, liste de diffusion noyau
- Documentation noyau sur l'allocation mémoire
- Documentation noyau sur la mémoire physique et les zones
Questions fréquentes
En quoi est ce différent de stress-ng ou d'un programme qui alloue beaucoup ?
La différence est la visée. Un programme en espace utilisateur qui alloue jusqu'à ce que quelque chose cède applique une pression à la machine entière, et ce que le noyau en fait dépend des allocations qui se trouvent en cours. Vous obtenez de la pression, mais vous n'en choisissez pas la forme, alors que le comportement intéressant est souvent très spécifique : une allocation d'un ordre précis qui échoue dans une zone précise sur un noeud précis. Page Alloc Hogger alloue depuis le noyau et prend le noeud, la zone, le type de migration et l'ordre en paramètres : la pression atterrit là où vous la pointez. Une seconde différence compte pour le débogage. Les allocations en espace utilisateur sont soumises au tueur OOM, si bien que l'outil qui applique la pression peut être le processus tué, ce qui met fin à l'expérience au moment précis où elle devient intéressante. Les allocations côté noyau n'ont pas ce problème.
Que sélectionnent réellement le noeud, la zone, le type de migration et l'ordre ?
Ce sont les quatre axes que l'allocateur de pages utilise pour décider d'où vient une page. Le noeud est le noeud NUMA, ce qui sur un serveur multi socket désigne le processeur auquel la mémoire est rattachée, donc son coût d'accès. La zone est une plage à l'intérieur d'un noeud, et sa raison d'être historique tient à des contraintes matérielles : certains périphériques ne peuvent adresser que la mémoire basse, si bien que le noyau garde des zones comme DMA, DMA32 et Normal séparées au lieu de traiter la mémoire comme un seul réservoir. Le type de migration décrit à quel point une page est déplaçable, ce dont le noyau se sert pour lutter contre la fragmentation en regroupant les allocations déplaçables afin de pouvoir les compacter plus tard. L'ordre est la taille, en puissance de deux pages : l'ordre zéro est une page unique, l'ordre neuf un bloc de deux mégaoctets. Pouvoir fixer les quatre est ce qui transforme un test de charge en reproduction.
Quels comportements du noyau cela permet il d observer ?
Ceux qui ne s'exécutent que lorsque la mémoire manque, ce qui est précisément pourquoi ils sont difficiles à étudier. La récupération directe se produit quand une allocation ne peut être satisfaite et que la tâche demandeuse doit elle même libérer de la mémoire avant de continuer, ce qui se manifeste par de la latence dans l'application plutôt que par une erreur. Kswapd en est la contrepartie en arrière plan, récupérant en avance de la demande pour que la récupération directe ne soit pas nécessaire. Le tueur OOM est le dernier recours lorsque la récupération ne suit plus. Les replis d'allocation surviennent quand la zone ou le type de migration préféré ne peut satisfaire la demande et que l'allocateur prend de la mémoire ailleurs, mécanisme derrière beaucoup de ralentissements liés à la fragmentation. Les quatre sont documentés et les quatre sont difficiles à déclencher volontairement : c'est le manque que visent ces correctifs.
Faut il faire tourner cela sur un serveur de production ?
Non, et la proposition dit explicitement que ce n'est pas destiné aux utilisateurs finaux. Cela vit dans DebugFS, un système de fichiers que beaucoup de configurations durcies ne montent déjà pas, et sa finalité entière est de consommer de la mémoire dont rien ne fera usage. L'exécuter sur un système de production revient à créer délibérément les conditions que vous passez votre temps à éviter. Les endroits réalistes sont une machine de test, une machine virtuelle jetable, ou un travail d'intégration continue qui vérifie le comportement de la gestion mémoire avant qu'un changement ne soit livré. Le public visé est composé de personnes qui écrivent ou déboguent du code noyau, plus celles qui doivent tester le comportement d'une application sous contrainte mémoire réelle, un besoin authentique dans l'embarqué et le mobile où le budget mémoire est fixe et serré.
Quel est le statut, et quand cela pourrait il arriver ?
C'est une demande de commentaires, le stade formel le plus précoce d'une proposition noyau. Une RFC signale que l'auteur veut un retour de conception plutôt qu'une relecture de correctif fini, et une part importante des séries RFC changent substantiellement ou ne sont jamais fusionnées. Rien n'est ici prévu pour une version, et il n'y a pas de cible. Les correctifs de gestion mémoire attirent par ailleurs un examen attentif, car le sous système est de ceux où une erreur coûte cher et où les mainteneurs sont d'autant plus conservateurs sur les nouvelles interfaces. La lecture pratique : cela vaut d'être connu si vous déboguez du comportement mémoire, d'être suivi sur la liste de diffusion si vous avez un avis sur l'interface, et pas encore d'être planifié.