Linux sait depuis un moment accorder a un processus une part garantie de memoire video via le cgroup de memoire de peripherique, et il manquait discretement a sa parole. Si des applications non protegees arrivaient les premieres et remplissaient la VRAM, une allocation protegee renoncait et atterrissait en memoire systeme plus lente au lieu de deloger qui que ce soit. Natalie Vock, de l'equipe graphique Linux de Valve, a passe huit tours de revue a corriger cela, et le resultat est prevu pour Linux 7.3. TTM evince desormais les tampons non proteges pour faire de la place. Le changement touche AMDGPU, Xe et Nouveau.
The short answer
Linux sait deja accorder a un cgroup une quantite protegee de memoire video via le controleur de memoire de peripherique, mais jusqu'ici la garantie n'etait pas appliquee. Quand la VRAM se remplissait de tampons non proteges, une allocation protegee basculait en memoire systeme au lieu de deloger quoi que ce soit. Natalie Vock, de l'equipe graphique Linux de Valve, a modifie TTM pour qu'il evince les tampons non proteges, en prenant soin d'eviter l'effet de balancier sur le bus. C'est prevu pour Linux 7.3, cela concerne AMDGPU, Xe et Nouveau, et cela ne fait quelque chose que si vous posez reellement une protection.
Une garantie que le systeme enregistre mais refuse d'appliquer vaut moins que pas de garantie du tout, parce que vous planifiez avec. C'est a peu pres l'etat dans lequel se trouvait le cgroup de memoire de peripherique : vous pouviez indiquer au noyau qu'une charge avait droit a un plancher de memoire video, la comptabilite vous donnait raison, et au moment d'agir le noyau trouvait une raison de ne pas le faire. La serie que Valve a fait accepter pour Linux 7.3 comble cet ecart.
Le repli poli qui vous coutait discretement de la VRAM
TTM est le gestionnaire de memoire partage sous les pilotes DRM, et l'une de ses taches consiste a decider si un tampon vit en VRAM ou en GTT, la memoire systeme qu'un GPU atteint via le bus. Basculer de la premiere vers la seconde est normal et generalement correct, parce qu'une allocation qui reussit lentement vaut mieux qu'une allocation qui echoue.
Le defaut, c'est que ce repli ne distinguait pas une allocation porteuse d'un droit d'une allocation qui n'en avait aucun. Des tampons non proteges remplissaient la carte. Une allocation protegee arrivait, ne trouvait pas de place et prenait la voie lente plutot que de deloger quoi que ce soit, alors meme que la memoire occupant l'espace n'y avait aucun droit. Natalie Vock decrit le correctif en disant que les applications peuvent desormais reellement utiliser toute la protection memoire que le systeme leur a accordee, facon polie de noter qu'elles ne le pouvaient pas avant.
Le nouveau comportement est direct : quand une allocation protegee ne tient pas, TTM tente d'evincer des tampons non proteges du domaine pour faire de la place, au lieu de renoncer immediatement.
Pourquoi il a fallu huit revisions
Parce que la version naive de ce correctif aggrave les choses. Si une allocation protegee evince un tampon non protege et que la charge non protegee y touche aussitot pour le ramener, la contention n'est pas resolue. Elle est convertie en trafic de bus, et les deux charges tournent desormais plus lentement qu'avec l'ancien comportement, qui laissait au moins les choses en place. C'est l'effet de balancier que la serie devait contourner par conception, et c'est le genre de probleme qui n'apparait qu'en revue, chez des gens qui l'ont deja vu se produire.
L'autre raison du cycle long, c'est la portee. TTM est du code commun. Modifier sa facon de decider une eviction, c'est modifier ce dont heritent AMDGPU, Xe et Nouveau, pour toutes les cartes que ces pilotes prennent en charge, soit une bonne part du parc graphique Linux. Faire relire cela correctement est plus lent que faire fusionner un contournement specifique a un pilote, et c'est aussi le bon choix, puisque l'alternative consiste en trois implementations divergentes de la meme politique.
Un element plus modeste a voyage avec la serie : une limite artificielle de 64 megaoctets est supprimee du code UDMABUF. Sans rapport avec le travail d'eviction, mais dans le meme ensemble.
Qui en profite reellement
Personne qui dispose de VRAM en abondance pour une seule charge. Autant le dire d'emblee, car la forme de ce changement se surinterprete facilement. Si votre carte n'est pas sous pression memoire, aucune allocation ne manque de place et le nouveau chemin d'eviction ne s'execute jamais.
La ou cela compte, c'est a l'autre extremite : un GPU de 8 gigaoctets qui fait tourner un jeu pendant qu'un navigateur conserve une pile de surfaces adossees au GPU, ou une console portable dont le systeme et la partie graphique partagent une seule reserve et ou la contention est simplement l'etat de repos. C'est le terrain de Valve, ce qui explique qui a ecrit les correctifs. Cela compte aussi pour qui partitionne un GPU entre locataires, ou vendre une garantie que le noyau n'honore pas revient a programmer un ticket de support.
La condition de tout cela, c'est la configuration. Le chemin d'eviction ne se declenche que pour les allocations porteuses d'une protection, et une allocation n'en porte que si vous en posez une via le cgroup de memoire de peripherique. Un bureau standard sans politique cgroup pour le GPU ne voit rien changer. Si vous evitiez ce reglage parce qu'il ne semblait pas faire grand-chose, Linux 7.3 est la version ou il se met a tenir sa promesse.
Sources et pour aller plus loin
- TTM memory management for graphics to be more aggressive with Linux 7.3, Phoronix, 7 aout 2026
- Fil de discussion sur les changements TTM de 7.3, Linux.org
- Archive des articles Phoronix sur TTM
Questions fréquentes
A quoi sert le cgroup de memoire de peripherique ?
C'est l'equivalent, pour la memoire video, du controleur de memoire que vous utilisez deja pour la RAM. Le cgroup de memoire de peripherique, generalement note DMEMCG, permet de decouper la memoire d'un GPU en reserves comptabilisees et d'accorder a un cgroup une quantite protegee, afin qu'une charge importante dispose d'un plancher fiable au lieu de se battre au premier arrive premier servi. Les cas d'usage sont evidents : un jeu ou un compositeur qui ne doit pas saccader, un service d'inference qui partage une carte avec du traitement par lots, une plateforme de conteneurs qui a vendu a quelqu'un une quantite de VRAM et aimerait la livrer. Le probleme jusqu'ici, c'est que la protection etait indicative au pire sens du terme. La comptabilite etait juste, la garantie etait enregistree, et au moment de l'appliquer le noyau se derobait. Corriger cela est ce qui rend le reglage digne d'etre pose.
Qu'est-ce qui ne fonctionnait pas avant cette serie de correctifs ?
Le chemin de repli etait trop poli. TTM gere la relation entre la VRAM et le GTT, la memoire systeme que le GPU atteint via le bus, et il est concu pour basculer de la premiere vers la seconde quand la memoire video vient a manquer. Ce repli est normalement le bon comportement, parce qu'une allocation lente vaut mieux qu'une allocation echouee. Le probleme, c'est qu'il se declenchait meme quand l'allocation disposait d'une garantie de protection et que la memoire occupant la VRAM n'en avait aucune. Des tampons non proteges remplissaient la carte, une allocation protegee arrivait, ne trouvait pas de place et prenait discretement la voie lente plutot que de deloger quoi que ce soit. Comme le formule Natalie Vock, le changement fait que les applications peuvent reellement utiliser toute la protection memoire que le systeme leur a accordee, facon diplomatique de dire qu'elles ne le pouvaient pas auparavant. La comptabilite avait toujours ete juste. C'est l'application qui n'avait jamais eu lieu.
Que fait le noyau differemment maintenant ?
Quand une allocation protegee ne tient pas, TTM tente d'evincer des tampons non proteges du domaine pour faire de la place au lieu de renoncer immediatement. C'est tout le changement en une phrase, et la subtilite consiste a eviter le mode de defaillance qu'il pourrait facilement creer. Une eviction naive produit un effet de balancier : l'allocation protegee pousse un tampon non protege en memoire systeme, la charge non protegee y touche a nouveau et le ramene, et les deux passent plus de temps a deplacer de la memoire sur le bus qu'a calculer. La serie est prudente sur le moment ou l'eviction est tentee, precisement pour eviter cela, ce qui explique en grande partie pourquoi il a fallu huit revisions plutot que deux. La serie supprime aussi une limite artificielle de 64 megaoctets dans le code UDMABUF, un rangement sans rapport qui a voyage avec elle.
Quels pilotes et quel materiel sont concernes ?
TTM est une infrastructure partagee plutot qu'un pilote, donc le changement arrive une fois et s'applique a tous les pilotes construits dessus : AMDGPU pour les cartes AMD, Xe pour les puces discretes et integrees recentes d'Intel, et Nouveau pour le materiel NVIDIA sur le pilote ouvert. Cette portee est l'argument qui justifie de corriger dans TTM plutot que dans un pilote, et c'est aussi pourquoi la revue a ete lente, car un changement de comportement dans du code commun de gestion memoire doit se defendre pour chacun de ses consommateurs. L'impact pratique se concentre la ou la VRAM est rare plutot que de se repartir uniformement. Sur une carte de 24 gigaoctets qui fait tourner une seule charge, rien de tout ceci ne se declenchera jamais. Sur un GPU de 8 gigaoctets, ou une console portable dont la memoire est partagee entre le systeme et la partie graphique, la contention est l'etat normal et la garantie est tout l'interet.
Faut-il configurer quelque chose pour en beneficier ?
Oui, et autant etre clair la-dessus, car ce n'est pas un correctif de performance gratuit. Le comportement d'eviction ne s'applique qu'aux allocations porteuses d'une garantie de protection, et rien n'en porte tant que vous n'avez pas configure le cgroup de memoire de peripherique pour en accorder une. Si vous faites tourner un bureau standard sans politique cgroup pour la memoire GPU, toutes vos allocations sont non protegees et le changement est invisible. La ou cela paie, c'est sur les systemes qui partitionnent deja un GPU volontairement : une image de console portable qui protege le cgroup du jeu, un hote de conteneurs qui alloue de la VRAM par locataire, une station de travail qui garantit a son compositeur son ensemble de travail pour que le bureau reste reactif pendant qu'une tache lourde s'execute. Pour ceux-la, la sequence devient enfin sensee : poser la protection, et attendre du noyau qu'il l'applique au lieu de l'enregistrer.