Serveurs : que faut-il attendre de l’architecture CXL ?
La technologie CXL promet essentiellement de partager la RAM entre les serveurs, ce qui doit permettre d’augmenter les performances sans les coûts. Mais il lui manque pour l’heure des mécanismes essentiels.
La technologie Compute Express Link (CXL) est censée étendre le bus PCIe pour en faire un réseau au sein duquel les serveurs pourraient se partager leur RAM, leurs GPUs et, bien évidemment, leurs SSD NVMe. Portant la promesse de construire des clusters plus modulaires – par exemple avec des modules qui ne contiennent que des GPUs, ou que des barrettes de DRAM, reliés à des switches PCIe – CXL consiste surtout à débarrasser les bus PCIe des protocoles qui les encombrent.
SI CXL vise l'augmentation des performances et, par conséquent, la réduction des investissements dans des composants plus performants, il n’en reste donc pas moins un changement architectural radical. Sachant qu’il est pour l’heure exclu de priver un serveur du fonctionnement normal des bus PCIe, la technologie CXL devrait exister comme un simple pilote qui prend la main sur certains canaux PCIe dans un serveur.
Quel changement architectural sont apportés par CXL ?
Jusqu'à présent, les systèmes qui comprenaient plusieurs types de composants (CPU, GPU et autres puces accélératrices pour l’IA ou les communications) décomposaient la mémoire en différents espaces - un pour le serveur, un pour le GPU et souvent un autre par puce d’accélération. D’un point de vue système, les partages de données entre chaque zone de mémoire étaient vus comme des transferts réseau ou, plus exactement, de type entrée/sortie, chacun avec une bande passante. Le problème de cette architecture est que, du point de vue du processeur, mettre à jour la mémoire du GPU est un processus beaucoup plus lent que de mettre à jour sa propre mémoire centrale.
Dans CXL, tout redevient une mémoire unique, le processeur pouvant accéder aussi simplement que le GPU à la mémoire de ce dernier.
Avant la technologie CXL, le serveur gérait les différentes zones de mémoire via les protocoles du bus PCIe. L'interface physique PCIe est rapide, mais le protocole ne l'est pas - en particulier pour les transferts de données volumineux. CXL permet aux administrateurs d'effectuer des transferts de données beaucoup plus rapidement. En revanche, le protocole CXL est plus limité que celui de PCIe.
Dans les faits, ce qui ralentit la gestion de la mémoire en PCIe est que les extensions sont gérées par des mécanismes de commutation de contexte, pilotés par des interruptions. Ces mécanismes n’existent pas entre un processeur et sa mémoire. CXL abolit les interruptions comme les mécanismes de commutation de contexte.
Avant CXL, les systèmes chargeaient une carte GPU de la même manière qu'ils écrivent sur un SSD NVMe : via un canal d’entrée-sortie PCIe. Un tel transfert comporte beaucoup de surcharge logicielle pour fonctionner. En convertissant ces accès en une sémantique standard de chargement de mémoire, cette surcharge disparaît et les systèmes peuvent rapidement copier les données de la mémoire du serveur vers celle du GPU. Les données circulent également dans l'autre sens, de sorte que les systèmes peuvent copier le contenu de la mémoire de l'accélérateur, d’IA par exemple, dans la mémoire du serveur hôte, comme s’il s’agissait simplement d’un échange de blocs.
Revers de la médaille, lorsque deux dispositifs indépendants accèdent à la mémoire de l'autre, il peut y avoir une perte de cohérence dans les données. Par exemple, si un processeur a mis en cache un certain segment de mémoire et qu'un accélérateur modifie ce segment mémoire, alors le système doit absolument mettre à jour la copie en cache. La technologie CXL s’accompagne de routines censées garantir que de tels événements sont correctement pris en charge.
Qui va bénéficier de l’architecture CXL ?
De manière globale, CXL sera sans doute déployé à terme sur tous les serveurs équipés en accélérateurs divers, dont des GPU, des DPU, des FPGA et autres ASIC. Mais la plupart des premiers utilisateurs de CXL seront a priori les fournisseurs de cloud. Leurs administrateurs peuvent utiliser CXL comme un mécanisme de partage de la mémoire entre de nombreux serveurs, ce qui rend cette technologie très intéressante pour les grandes installations. En l’occurrence, elle contribue ici à améliorer le débit du datacenter sans devoir installer de la RAM en plus dans chaque serveur et en préservant les clusters de serveurs du goulet d’étranglement des protocoles réseau.
Les grands hébergeurs de cloud public, les hyperscalers, voient dans CXL la possibilité de partager entre leurs serveurs des pools de barrettes de DRAM. Dans le cas d’une ferme géante de, disons, 20 000 serveurs, chaque machine est configurée avec une quantité de mémoire identique. Sans CXL, une machine qui a trop peu de RAM à offrir à une application ralentit le fonctionnement de cette application, car elle devra plus souvent accéder à des baies de stockage pour compenser.
Augmenter la quantité de RAM pour parer à toute éventualité coûte bien trop cher au regard de la fréquence de ces éventualités. Pire, tous les composants de DRAM installés consomment de l’énergie, même quand ils ne sont pas utilisés par une application. D’ailleurs, une bonne pratique dans la gestion énergétique des datacenters consiste à réduire le nombre de barrettes.
Il n’est pas non plus question pour ces hébergeurs de dédier certaines machines plus fortement pourvues en mémoire à des applications particulières. Cela irait à l’encontre des principes d’architecture composable et de virtualisation, lesquels permettent aux hébergeurs de rationaliser leur flotte informatique en allouant librement les tâches à n’importe quel serveur, en partant du principe que tous les serveurs du centre de données sont équivalents.
La solution – offerte par CXL – consiste donc à aller chercher sur un autre serveur la mémoire qui manque à une application. Dit autrement, les applications qui nécessitent une mémoire importante peuvent emprunter une partie de la mémoire au pool global et la restituer une fois la tâche terminée. De cette façon, les serveurs individuels peuvent contenir relativement peu de barrettes de DRAM et emprunter ce dont ils ont besoin à un serveur qui se trouve de l’autre côté d’un canal CXL. On parle dès lors de mémoire proche, pour les barrettes de DRAM internes à un serveur, et de mémoire lointaine, pour celles qui se trouvent sur un autre serveur atteignable via CXL.
Quels sont les nouveaux enjeux techniques posés par CXL ?
La technologie CXL est censée aider le système à déterminer quelles applications doivent bénéficier d'une augmentation des performances et lesquelles n’en ont pas besoin. Mais encore faut-il qu’elle soit équipée d’un outil de supervision adéquat.
Dans un premier temps, les architectes ont imaginé que le scénario d’usage serait assez simple. Un datacenter exécute une application A, qui bénéficie d'une forte augmentation de performances chaque fois que la taille de sa mémoire est doublée, une application B, qui bénéficie d'une augmentation plus modeste de ses performances, et une application C qui n'est que légèrement affectée par la taille de la mémoire.
Dans ce scénario, tout système qui exécute des instances de l'application A doit allouer autant de mémoire partagée que possible à cette application et doit allouer tout ce qui reste à l'application B. S'il n'y a pas d'instances de l'application A dans le datacenter, alors l'application B doit obtenir la plus grande partie du pool de mémoire partagé, les restes allant à l'application C.
Mais, en pratique, cette logique ne fonctionne pas. Au-delà d’une certaine quantité de mémoire disponible, les performances d’une application n’augmentent plus autant. Et l’on peut se retrouver dans une situation où un bloc mémoire libéré serait automatiquement alloué une instance de l’application A pour améliorer ses performances de 11%, alors qu’il aurait pu améliorer les performances de l’application B de 12%.
L’outil de supervision qui résoudra ces problématiques n’existe pas encore. Cela pose le risque de se retrouver dans un premier temps avec une utilisation anarchique des ressources dans les pools partagés entre tous les serveurs. Selon les spécialistes du domaine, parvenir à partager la mémoire inutilisée entre les serveurs est déjà un exploit technique en soi, qui plus est avec un pilote qui s’assure qu’aucune incohérence n’est engendrée. Il faut donc pardonner à la technologie si elle n’est pas encore prête à s’installer dans le tout-venant des datacenters.
Notons que CXL a aussi ses détracteurs. Comme la technologie est principalement due à une initiative d’Intel, certains l’ont catalogué comme un système dédié à la mise en réseau de modules Optane et se demandent aujourd’hui si CXL n’est pas mort-né à cause de l’abandon d’Optane. En pratique, la décision d’Intel d’abandonner les produits Optane ne devrait avoir aucune conséquence sur la carrière de CXL.
