Alex Deucher, mainteneur d'AMDGPU, a envoyé deux séries de correctifs sur la liste de diffusion du noyau Linux le vendredi vingt et un août 2026, pour prendre en charge Ultra Accelerator Link. La première compte 95 correctifs et environ sept mille lignes, entre infrastructure de base et intégration dans le pilote AMDGPU. La seconde compte trois correctifs portant l'interface IOCTL destinée à l'espace utilisateur et la documentation. UALink est le réseau ouvert de mise à l'échelle verticale qui relie les accélérateurs au sein d'un pod, spécifié pour mille vingt quatre appareils dans un même domaine. Le plus intéressant n'est pas le protocole. C'est que le noyau doit désormais gérer de la mémoire distante qui ne lui appartient pas.
The short answer
Alex Deucher, mainteneur d'AMDGPU, a publié deux séries UALink sur la liste noyau le vendredi vingt et un août 2026. La première porte 95 correctifs et environ sept mille lignes d'infrastructure de base et d'intégration AMDGPU, dont le partitionnement de l'espace d'adressage physique réseau et les invalidations de TLB distantes pour la mémoire qui se déplace. La seconde ajoute trois correctifs avec l'interface IOCTL et la documentation. UALink est le réseau vertical ouvert spécifié pour des pods de 1 024 accélérateurs.
La plupart des prises en charge d'interconnexion dans le noyau tiennent en un pilote, quelques files et beaucoup de gestion d'erreurs. Celle-ci est plus vaste, et la raison apparaît dans le code de gestion mémoire plutôt que dans le transport.
Deux séries, un réseau
Alex Deucher, qui maintient AMDGPU, a publié les deux séries le 21 août. La première est la plus lourde : 95 correctifs, environ sept mille lignes, ajoutant l'infrastructure noyau pour Ultra Accelerator Link ainsi que l'intégration dans le pilote AMDGPU. La seconde compte trois correctifs qui exposent l'interface IOCTL à l'espace utilisateur et documentent la façon de piloter le partage de mémoire à travers un pod.
UALink est une norme ouverte développée par un consortium dont les membres incluent AMD, Broadcom, Intel, Google et Microsoft. C'est un réseau de mise à l'échelle verticale destiné à relier les accélérateurs au sein d'un pod, spécifié pour connecter jusqu'à mille vingt quatre appareils dans un seul domaine.
Vertical n'est pas horizontal
La distinction est tout l'enjeu et elle se brouille facilement.
Un réseau horizontal transporte des messages entre nœuds. Ethernet et InfiniBand sont horizontaux : le logiciel décide d'envoyer quelque chose, le réseau le livre, et le récepteur décide quoi en faire. Le modèle de programmation est une communication explicite, et le budget de latence se compte en microsecondes.
Un réseau vertical présente la mémoire distante comme de la mémoire. Un GPU émet une lecture ou une écriture ordinaire vers une adresse, et le réseau la résout vers de la mémoire physique qui se trouve sur un autre appareil de la baie. Pas d'envoi, pas de réception, pas de copie. C'est ce que fait NVLink dans un pod Nvidia, et c'est ce qu'UALink est spécifié pour faire sans dépendre d'un seul fournisseur.
PCIe sait déjà faire des transferts entre pairs, donc ce n'est pas une capacité nouvelle par nature. C'est une différence de débit, de latence et de nombre d'appareils suffisamment large pour que le modèle logiciel change : avec du PCIe entre pairs vous préparez les données, avec un réseau vertical vous les adressez.
Le difficile, c'est la mémoire qui bouge
C'est du côté noyau que vient le nombre de correctifs.
La série introduit le partitionnement de l'espace d'adressage physique réseau entre les accélérateurs d'un pod, pour qu'une lecture ou une écriture émise par un appareil se résolve vers la bonne mémoire physique sur un autre. Elle gère l'autorisation d'exporter une plage mémoire depuis un appareil et de l'importer sur un autre, car laisser n'importe quel appareil d'un pod adresser la mémoire de n'importe quel autre sans modèle de permission serait une faute évidente.
Vient ensuite la partie qui génère l'essentiel de la complexité. La mémoire d'un accélérateur n'est pas figée. Le gestionnaire mémoire TTM évince des tampons sous pression, et les notificateurs MMU se déclenchent quand les projections de l'espace utilisateur changent en dessous. Quand la mémoire se déplace, chaque importateur qui avait mis en cache une traduction d'adresse détient désormais une traduction qui pointe au mauvais endroit.
La série répond par des invalidations de TLB distantes sur l'exportateur, déclenchées lors des évictions TTM et des rappels de notificateurs MMU, pour que les importateurs invalident leurs traductions en cache avant que la mémoire ne bouge.
Quiconque a déjà débogué une entrée de TLB obsolète sur une seule machine reconnaîtra le mode de défaillance, et reconnaîtra aussi qu'étendre cela à un réseau élargit la fenêtre et rend le débogage bien pire. Bien faire cela en relecture compte davantage que le fusionner vite.
La suite
Aucune cible de fusion n'accompagne ces séries, et il serait inhabituel qu'un ensemble de cette taille soit intégré dans le cycle de sa première publication. Quatre-vingt-quinze correctifs touchant l'infrastructure de base et un pilote majeur mobilisent la relecture de plusieurs sous-systèmes, et les interactions avec la gestion mémoire seront lues de près.
La lecture réaliste est que c'est l'ouverture de la relecture en amont, pas une fonctionnalité autour de laquelle planifier. Ce que cela établit, c'est que la prise en charge se construit sur la liste de diffusion publique et non dans un arbre propriétaire, ce qui fait la différence entre un réseau que votre noyau de distribution finira par prendre en charge et un réseau qui exigera une pile propriétaire pour toujours.
Pour la plupart des lecteurs, cela ne change rien au quotidien. Si vous dimensionnez de la capacité pour de l'entraînement ou de l'inférence à grande échelle, en revanche, l'existence d'un réseau vertical ouvert crédible avec une prise en charge en amont est une question de fournisseurs et non de performances, et ce genre de question pèse davantage sur un cycle matériel de trois ans qu'un écart de test.
Sources et pour aller plus loin
- AMD publie une série massive de correctifs pour UALink dans le noyau Linux, Phoronix, 21 août 2026
- Ultra Accelerator Link, interconnexion ouverte pour accélérateurs IA, consortium UALink
Questions fréquentes
Qu'est-ce qu'UALink et en quoi diffère-t-il de PCIe ou d'Ethernet ?
Ultra Accelerator Link est une interconnexion normalisée et ouverte de mise à l'échelle verticale pour accélérateurs au sein d'un même pod, développée par un consortium réunissant notamment AMD, Broadcom, Intel, Google et Microsoft. La distinction qui compte oppose mise à l'échelle verticale et horizontale. Ethernet et InfiniBand relèvent de l'horizontale : ils transportent des messages entre nœuds, et le logiciel émet et reçoit explicitement. UALink relève de la verticale et présente la mémoire d'un accélérateur distant comme de la mémoire, si bien qu'un GPU émet de simples instructions de lecture et d'écriture vers une adresse qui réside physiquement sur un autre appareil. PCIe sait faire des transferts entre pairs, mais pas au débit, à la latence ni au nombre d'appareils visés par UALink.
Que contiennent réellement les deux séries de correctifs ?
La première série compte 95 correctifs et environ sept mille lignes. Elle ajoute l'infrastructure noyau de base pour UALink ainsi que l'intégration dans le pilote graphique AMDGPU, y compris le partitionnement de l'espace d'adressage physique réseau entre les accélérateurs d'un pod pour que les lectures et écritures directes se résolvent vers le bon appareil. Elle gère aussi l'autorisation d'exporter et d'importer de la mémoire entre appareils. La seconde série compte trois correctifs qui exposent l'interface IOCTL à l'espace utilisateur et ajoutent la documentation décrivant comment piloter le partage de mémoire entre GPU d'un pod.
Pourquoi des invalidations de TLB distantes ?
Parce que la mémoire distante peut bouger. Quand un GPU importe une plage de mémoire d'un autre GPU, l'importateur met en cache les traductions d'adresses correspondantes. Si l'appareil exportateur déplace ou évince ensuite cette mémoire, via une éviction TTM ou le déclenchement d'un notificateur MMU, toutes les traductions en cache pointant vers l'ancien emplacement deviennent obsolètes et résoudraient vers la mauvaise mémoire physique. La série émet donc des invalidations de TLB distantes sur l'exportateur pour que les importateurs invalident leurs traductions avant que le déplacement ne s'achève. C'est le même problème de cohérence qu'une invalidation de TLB multiprocesseur, étendu à un réseau plutôt qu'à des cœurs.
Quand cela pourrait-il arriver dans un noyau publié ?
Aucune date de fusion n'est annoncée, et il serait inhabituel qu'une série de cette taille soit intégrée dès le cycle de sa publication. Quatre-vingt-quinze correctifs touchant l'infrastructure de base et un pilote majeur attirent la relecture de plusieurs sous-systèmes, et les interactions avec la gestion mémoire suscitent en particulier un examen minutieux. Voyez cela comme le début de la relecture en amont plutôt que comme une fonctionnalité autour de laquelle planifier un déploiement. Ce que cela confirme, c'est qu'AMD construit la prise en charge au grand jour sur la liste de diffusion, ce qui est la voie vers un réseau pris en charge par un noyau de distribution plutôt que par un arbre propriétaire.
Est-ce important si je n'exploite pas de pod de GPU ?
Pas directement, et la plupart des gens n'en exploiteront jamais. C'est important comme signal sur la direction que prend l'interconnexion d'accélérateurs, car l'alternative ouverte à un réseau vertical propriétaire ne devient réelle que lorsque la prise en charge noyau existe et arrive dans les distributions. Si vous dimensionnez de la capacité pour de l'entraînement ou de l'inférence à grande échelle, la présence ou l'absence d'une option verticale ouverte modifie vos choix de fournisseurs d'une manière que les tests de performance ne traduisent pas. Et si vous travaillez sur la gestion mémoire du noyau, la conception de l'invalidation distante mérite la lecture pour elle-même.