Memtide

Le problème

La mémoire CXL étend la capacité d’un serveur au-delà de ses barrettes DRAM, mais son accès est sensiblement plus lent. On gagne donc en capacité ce que l’on risque de perdre en performance : une page « chaude », souvent accédée, laissée sur le palier CXL pénalise tout le système ; une page « froide » qui occupe de la DRAM gaspille la ressource rapide. Le placement des pages entre les deux paliers décide à lui seul du bénéfice réel du CXL.

Le noyau Linux sait migrer des pages, mais il ne choisit pas seul lesquelles déplacer ni quand, au regard d’un objectif applicatif. Memtide comble ce vide : un orchestrateur qui observe, score et déplace les pages depuis l’espace utilisateur.

Mesurer la chaleur

Tout repose sur la qualité du signal : mal estimer la chaleur d’une page, c’est migrer à contretemps et dégrader ce que l’on cherchait à améliorer. Plutôt qu’une source unique, Memtide en croise plusieurs :

• PSI (pressure stall information), qui révèle quand le système attend réellement la mémoire ;
• MGLRU, dont les générations donnent une approximation peu coûteuse de l’ancienneté des pages ;
• les défauts de page instrumentés en eBPF, pour observer les accès sans modifier les applications ni payer un traçage lourd ;
• des signaux TLB comme indice de localité.

Croiser ces sources donne un score plus stable qu’aucune ne le permet seule, et assez léger pour tourner en continu.

Décider et migrer

Le pipeline va du signal à l’action : collecte, scoring, migration. Une page jugée chaude ou froide est déplacée via move_pages(2) pour un placement explicite, ou poussée vers le palier lent par memory.reclaim. L’ensemble s’appuie sur cgroup v2 et un noyau ≥ 6.1, ce qui permet de cibler des charges précises sans toucher au reste de l’hôte.

Ne jamais dégrader l’hôte

Un orchestrateur mémoire qui se trompe peut faire plus de mal que de bien. C’est la contrainte qui a le plus pesé sur la conception : Memtide doit pouvoir échouer proprement. Deux garde-fous l’encadrent. Un kill-switch rend la main au noyau instantanément, en rétablissant le comportement par défaut. Un circuit breaker suspend les migrations dès que les indicateurs se dégradent (trop de déplacements, une pression qui monte au lieu de baisser) plutôt que de s’entêter. Dans le pire cas, le système se comporte comme si Memtide n’était pas là.

Pourquoi en espace utilisateur

J’ai délibérément placé la logique en userspace plutôt qu’en module noyau. La décision (quels signaux croiser, quelle politique de scoring, quels seuils retenir) est la partie qui évolue le plus vite ; l’itérer hors du noyau réduit la surface de risque, simplifie le débogage et permet de changer de politique sans recompiler un kernel. Le noyau fournit les primitives (migration, reclaim, signaux) ; Memtide porte la politique.

Validation et état

Tester du tiering CXL sans matériel CXL n’a rien d’évident. J’ai monté un banc dédié sous QEMU/KVM, avec un noyau instrumenté (DAMON) qui reproduit les paliers et expose les migrations à la mesure (voir Banc d’essai CXL/DAMON).

État : MVP v0.1. La chaîne décision → exécution fonctionne de bout en bout, garde-fous compris. Projet personnel, code privé, ouverture possible sur demande.