Outils sysadminActualité

Page Alloc Hogger : mémoire libre et bloc contigu

Sur cette page
  1. Une RFC pour une pression contrôlée
  2. La taille d’allocation a une unité
  3. Quoi relever pour reproduire le problème

Une pression mémoire ciblée peut aider à reproduire les bugs d’allocation. Encore faut-il distinguer le nombre de pages libres de l’existence d’un bloc contigu adapté.

Deux dispositions fictives de seize pages de 4 Kio ont chacune huit pages libres, soit 32 Kio. Seule celle du haut offre immédiatement un bloc libre aligné de huit pages. Récupération ou compaction peuvent modifier l’autre.
Deux dispositions fictives de seize pages de 4 Kio ont chacune huit pages libres, soit 32 Kio. Seule celle du haut offre immédiatement un bloc libre aligné de huit pages. Récupération ou compaction peuvent modifier l’autre. Graphique : PeopleAreGeek. Source des données.
Agrandir l’image

Une RFC pour une pression contrôlée

Juan Yescas a publié la RFC v2 le 6 août UTC. Elle propose d’allouer puis libérer des pages via debugfs en sélectionnant nœud, zone, ordre et type de migration. Cette version exclut ZONE_DEVICE et ne prend pas encore en charge MIGRATE_CMA.

La discussion de revue compte autant que la liste initiale : les mainteneurs préfèrent séparer le mécanisme du cœur de la gestion mémoire, et discutent d’un emplacement dans les outils de test. Ce n’est pas une fonction utilisateur promise pour une version déterminée du noyau.

La taille d’allocation a une unité

Une allocation d’ordre n contient 2 puissance n pages de base. Avec des pages de 4 Kio, l’ordre 9 représente 512 pages, soit 2 Mio. L’ancien texte omettait cette hypothèse : un ordre n’est pas une quantité d’octets indépendante de l’architecture.

La couverture prend un exemple fictif plus petit : seize pages de 4 Kio, dont huit libres sur chaque ligne. Les deux disposent donc de 32 Kio libres. Sur la première, les huit premières pages constituent un bloc libre aligné, compatible localement avec une demande d’ordre 3. Sur la seconde, l’alternance de pages occupées interrompt tous les blocs de cette taille.

L’exemple isole volontairement la disposition à un instant donné. Un allocateur réel peut récupérer, compacter ou utiliser un repli selon ses options et sa politique. Le dessin ne prédit pas un échec permanent, ne reproduit pas un benchmark et ne décrit pas une machine mesurée.

Quoi relever pour reproduire le problème

L’expérience utile documente taille des pages, révision du noyau, options de requête, nœud et zone ciblés, puis distribution des blocs libres avant et après. Y associer latence ou échecs du programme étudié. « Il restait de la RAM » omet précisément les distinctions exposées par l’outil proposé.

L’espace utilisateur peut déjà influencer le placement NUMA : affirmer qu’il ne choisit aucun de ces paramètres était excessif. Le module propose surtout une interface particulière vers l’allocateur et des allocations noyau conservées ; il n’invente pas tous les tests mémoire ciblés.

Nous n’avons ni chargé le module ni soumis un serveur à cette pression. L’exemple explique calcul et disposition. Un outil de stress de l’allocateur se teste sur une machine jetable, avec une procédure explicite de libération et de récupération du système.

Revue du 8 septembre : RFC v2 et orientation vers les outils de test précisées, unités d’ordre corrigées et fragmentation illustrée sans générer de pression réelle.