La proposition UALink d’AMD du 21 août a déjà évolué. La version du 31 août décrit une mémoire exportée fixée, contrairement à l’explication initiale fondée sur des allocations déplaçables. Il s’agit de code soumis à revue, pas d’un support universel sous Linux.
Ce que dit la série révisée
La présentation des 95 correctifs v2 décrit l’infrastructure et l’intégration AMDGPU pour UALoE, UALink over Ethernet. Une série distincte de trois correctifs couvre l’interface applicative et la documentation. Ces rôles rendent le nombre de correctifs plus parlant qu’un simple interrupteur de fonctionnalité.
La documentation actualisée précise que la mémoire exportée est fixée en place, ou pinned. Les invalidations de traduction distantes retirent l’accès lors de sa libération. L’ancienne explication fondée sur des évictions déplaçant ces allocations ne correspond pas à cette révision. La première série désactive conditionnellement l’interface de configuration sysfs proposée, dont le retrait est prévu. Des outils de configuration hors bande sont envisagés dans un premier temps.
Une adresse n’autorise pas l’accès à toute la mémoire
La proposition répartit un espace Network Physical Address entre GPU. Le propriétaire exporte une allocation et obtient un handle opaque. Un importateur autorisé utilise ce handle pour créer une référence locale vers cette allocation distante. L’espace d’adressage partagé ne signifie pas que chaque processus lit toute la mémoire de chaque GPU.
Prenons une explication originale : le GPU A possède les buffers X et Y, tandis que B reçoit l’autorisation d’importer X. Transmettre le handle de X ne doit pas être présenté comme un accès à Y. Après la libération de X, l’ancienne référence de B ne doit pas maintenir un droit sur du stockage susceptible de changer d’usage. Durée de vie et invalidation comptent donc autant que le débit du lien.
Cet exemple explique la relation de propriété ; ce n’est ni un test du mécanisme d’autorisation ni un plan physique de rack AMD.
Éviter le raccourci Ethernet contre mémoire
La proposition emploie elle-même Ethernet comme transport tout en exposant des opérations de mémoire distante à l’échelle du pod. Elle contredit donc l’idée qu’Ethernet impose forcément un échange explicite de messages au niveau applicatif. Technologie du lien, sémantique du transport et interface du programme sont des niveaux distincts.
Les lectures et écritures distantes directes ne rendent pas non plus la communication gratuite. Elles décrivent la manière d’exprimer l’accès, pas une latence nulle ou une absence de transfert.
Pour préparer un déploiement, cherchez le code accepté dans le noyau, le moteur utilisateur correspondant, les plateformes prises en charge et leur configuration documentée. Publier une série rend l’implémentation examinable ; cela n’engage pas à elle seule Linux 7.4 ou une autre version à l’intégrer.
Revue du 8 septembre : faits et évolutions vérifiés, explications et médias repris.