A l’heure où le développement de l’IA pèse sur la consommation énergétique des datacenters, toute initiative pour limiter cette fuite en avant est la bienvenue. Dans ce cadre, Martin Karsten, professeur à Waterloo, et Joe Damato, ingénieur distingué chez Fastly, tous deux chercheurs de l'université canadienne de Waterloo, ont réussi à améliorer la manière dont Linux gère le trafic réseau, et tout cela en 30 lignes de code. Cette minuscule modification pourrait rendre plus efficace le fonctionnement des applications au sein des centres de données tout en économisant de l'énergie. Le code en question est basé sur une recherche décrite dans un article de 2023 signé par Martin Karsten et Peter Cai, étudiant diplômé. En analysant le réseau au niveau du noyau par rapport au réseau au niveau de l'utilisateur, ce dernier a déterminé qu'un petit changement pourrait non seulement augmenter l'efficacité de l'application, mais aussi réduire la consommation d'énergie du datacenter jusqu'à 30 %.
Le code, accepté et inclus à la version 6.13 du noyau Linux, ajoute un autre paramètre de configuration NAPI, irq_suspend_timeout, pour équilibrer l'utilisation du processeur et l'efficacité du traitement réseau lors de l'utilisation de l'IRQ deferral et du napi busy poll. Cet équilibrage entraîne une bascule automatiqueme entre deux modes de fourniture de données à une application – le mode par interrogation ou « polling » et le mode par interruption ou « interrupt-driven » - en fonction du trafic réseau, afin de maximiser l'efficacité. En mode « polling », l'application demande des données, les traite, puis en redemande, dans un cycle continu. En mode « interrupt-driven », l'application reste en sommeil, économisant de l'énergie et des ressources jusqu'à ce que le trafic réseau qui lui est destiné arrive, puis se réveille et le traite. « Si l’on dispose d'un serveur multi-utilisateurs et multi-processus à l'ancienne avec de nombreuses applications (de petite taille) fonctionnant simultanément, ce mécanisme n'apportera rien de plus, mais ne devrait pas nuire non plus », a indiqué M. Karsten.
Des scénarios mieux adaptés que d’autres
Cependant, le chercheur explique que dans de nombreux scénarios de centres de données, les machines serveurs exécutent un petit nombre d'applications sur des serveur dédiées. « Ces applications 'dominent' un ensemble de cœurs et peuvent généralement être connectées à un ensemble de files d'attente de transmission dans la carte d'interface réseau. Notre mécanisme est utile pour ce type d'applications, si elles traitent également beaucoup de trafic réseau. C'est le cas de presque tous les serveurs front-end, mais aussi de nombreux serveurs dorsaux qui fournissent des données aux serveurs frontaux. » Quand le trafic réseau est important, il est plus efficace et plus performant de désactiver le mode par interruption et de fonctionner en mode par interrogation. En revanche, quand le trafic réseau est faible, c'est le traitement par interruption qui fonctionne le mieux. « Une implémentation n'utilisant que le polling gaspillerait beaucoup de ressources/énergie pendant les périodes de faible trafic. Une implémentation n'utilisant que des interruptions devient inefficace en cas de trafic important. Les économies d'énergie les plus importantes sont donc réalisées quand on compare une implémentation performante en mode interrogation permanente durant les périodes de faible trafic », a poursuivi M. Karsten. « Notre mécanisme détecte automatiquement [la quantité de trafic réseau] et bascule entre le mode par interrogation et le mode par interruption pour obtenir le meilleur des deux mondes. »
Dans la lettre d'accompagnement du code, M. Damato décrit plus en détail la mise en œuvre du paramètre : « Ce mode de livraison est efficace, car il évite que l'exécution des softIRQ n'interfère avec le traitement des applications pendant les périodes d'activité intense. Il peut être utilisé en bloquant epoll_wait pour conserver les cycles de CPU durant les périodes d'inactivité. L'alternance entre les périodes actives et les périodes d'inactivité fait que les performances (débit et latence) sont très proches de celles du mode polling en période de forte activité, tandis que l'utilisation du CPU est plus faible et très proche du mode interrupt-driven atténué. » M. Karsten ajoute encore que « sur le plan pratique, l'activation de la fonction nécessite une petite modification des applications et le réglage d'une variable de configuration du système. Et même s’il ne peut pas encore quantifier les avantages énergétiques de la technique (l'économie de 30 % citée est le meilleur cas), il pense que « les économies d'énergie les plus importantes se produisent quand on les compare à une implémentation d’un mode par interrogation permanente à haute performance pendant les périodes de faible trafic. »
Commentaire