En modifiant seulement 30 lignes de code Linux, il est possible de réduire la consommation électrique jusqu’à 30 %

• Aux États-Unis, les centres de données ont consommé en 2023 environ 4 % de l’électricité nationale, un chiffre qui devrait monter à 12 % d’ici 2028
• Une équipe de recherche de l’Université de Waterloo a mis au point une méthode permettant de réduire jusqu’à 30 % la consommation électrique des data centers en améliorant la manière dont le noyau Linux traite le réseau
• L’élément clé est le contrôle dynamique du busy polling, avec bascule automatique entre interruptions et polling selon le trafic
• Cette modification a été réalisée avec seulement une trentaine de lignes de code changées et a été officiellement intégrée au noyau Linux 6.13
• Elle présente un fort potentiel d’adoption dans les data centers et les serveurs web basés sur Linux, tout en soulignant l’importance de revenir à une philosophie de développement logiciel centrée sur l’efficacité

---

La consommation électrique des data centers peut être réduite jusqu’à 30 % avec seulement 30 lignes de code dans le noyau Linux

Inquiétudes face à la hausse de la consommation électrique

• La majeure partie du trafic web mondial transite par des data centers, qui servent aussi de base à des applications très énergivores comme les services d’IA
• Aux États-Unis, les data centers ont utilisé environ 4 % de l’électricité en 2023, et cette part devrait atteindre 12 % d’ici 2028

Le cœur du problème : la manière dont le noyau Linux traite le réseau

• Le noyau Linux combine interruptions et polling pour le traitement des paquets réseau
  • Interruption : lorsqu’un nouveau paquet arrive, le CPU interrompt sa tâche en cours pour le traiter
  • busy polling : pour réduire la latence, le système vérifie périodiquement la présence de paquets même s’il n’y en a pas → inefficacité

La solution : basculer dynamiquement le busy polling

• L’équipe du professeur Martin Karsten à l’Université de Waterloo propose, selon le trafic réseau :
  • quand le trafic est élevé : utiliser le busy polling
  • quand le trafic est faible : revenir au mode interruption
• Résultat : moins de consommation électrique inutile et davantage de flexibilité

Modification du code et état du déploiement

• La solution a été mise en œuvre en collaboration avec l’ingénieur de Fastly Joe Damato, en réorganisant le code existant du noyau
• Sans écrire de nouveau code, la modification a consisté à restructurer l’existant pour un total d’environ 30 lignes changées
• Elle a été officiellement intégrée au noyau Linux 6.13 (sorti en janvier 2025)
  → Commit du noyau

Effets sur la réduction de la consommation énergétique

• Pour les applications fortement centrées sur le réseau, la réduction peut atteindre 30 % de consommation électrique
  • pour les applications plus générales, le gain peut être moindre
• Comme le système s’adapte automatiquement aux variations du trafic, il est particulièrement adapté aux data centers
• L’approche pourrait aussi être étendue aux serveurs web basés sur Linux (nginx, Apache, etc.)

Diffusion dans la communauté et impact open source

• Damato prévoit également d’appliquer cette technique au serveur H2O de Fastly
• Comme il s’agit de code de noyau open source, les développeurs d’autres serveurs web peuvent eux aussi s’en inspirer
• On espère qu’elle servira de catalyseur pour restaurer une culture de développement centrée sur l’efficacité énergétique

Portée philosophique de la recherche

• « Dans les années 90, l’optimisation des ressources était un fondement de l’informatique », mais depuis vingt ans, la performance a pris le dessus et l’efficacité a été négligée
• Cette recherche montre qu’« une petite amélioration du code peut conduire à d’énormes économies d’énergie » et propose une direction pour un développement logiciel durable

[GN⁺]

Avis Hacker News

• Linux a ajouté une fonctionnalité de polling actif pour le réseau haute performance. La plupart des logiciels Linux ne l’utilisent pas, mais pour les logiciels utilisés dans les datacenters, cela est peu efficace énergétiquement lorsque le système n’est pas occupé. Ce correctif permet de le désactiver quand le système n’est pas occupé et de retrouver une meilleure efficacité énergétique.

  • Le titre de l’article est un peu trompeur. On pourrait croire que cela s’applique aussi aux tâches sur poste de travail, alors qu’en réalité cela concerne les datacenters. Ajouter « in datacenters » dans le titre aurait évité la confusion.

• Une grande partie des charges de travail de datacenter haute performance ne passent en réalité pas par la pile réseau du noyau Linux.

  • À la place, elles utilisent DPDK, XDP ou des piles en espace utilisateur comme Onload ou VMA. Souvent, des SmartNICs assurent la décharge matérielle. Dans ces cas, ce correctif ne s’applique pas.
  • En revanche, ce correctif aide clairement dans les configurations où le noyau est dans le chemin de données (CDN, nœuds d’ingress, VM, systèmes Linux embarqués, etc.). Il n’aura sans doute pas beaucoup d’effet sur les charges qui contournent déjà le noyau pour des raisons de performance ou de latence. L’annonce de 30 % d’économies d’énergie dépendra énormément du contexte.

• On peut trouver davantage de détails sur ce changement ici : https://lwn.net/Articles/1008399/

• C’est un changement vraiment remarquable. En tant que spécialiste du calcul haute performance, je me suis souvent demandé quelle quantité d’énergie est gaspillée à cause de code inefficace, et à quel point cela devient un problème majeur à mesure que l’informatique à l’échelle planétaire continue de s’étendre.

  • Personnellement, j’ai le sentiment qu’il existe une obligation morale à rendre le code aussi efficace que possible. C’est d’autant plus vrai quand une tâche tourne pendant des mois sur des centaines de CPU.

• À l’inverse, Meta dispose de hacks pour garder les GPU occupés afin de rendre la consommation électrique plus stable pendant l’entraînement des LLM. Par exemple, ils ne veulent pas d’une forte chute de consommation lors de la synchronisation des batchs.

• Est-ce que cela signifie que « l’atténuation adaptative des interruptions » n’est plus utilisée dans le noyau ? Cela fait bien plus de 15 ans que je n’ai pas travaillé sur ce sujet, mais le noyau s’adaptait autrefois en utilisant des interruptions quand le débit réseau était faible, puis en désactivant les interruptions au-delà d’un certain seuil pour passer au polling.

  • Le problème qu’on cherchait à résoudre était celui des variations soudaines et extrêmes du trafic. Par exemple, lorsqu’une boucle est introduite dans le switching et provoque la tempête de paquets qui s’ensuit. Dans ce cas, les interruptions arrivaient si vite que le système n’avait jamais assez de temps hors interruption pour pouvoir les désactiver. La solution consistait donc à faire en sorte qu’un routeur Linux dispose de davantage de cœurs que son interface réseau.

• Quand une phrase contient « Up To », alors littéralement tout devient possible.

• Hors sujet, mais je suis heureux de relire quelque chose sur Joe Damato. Cela me rappelle de vieux souvenirs. Après avoir lu à l’époque l’article de James Gollick sur tcmalloc et découvert packagecloud.io, j’étais ensuite tombé sur les excellents articles de Joe.

• Paragraphe clé :

  • « Ces économies d’énergie s’accompagnent de réserves. “Les 30 % correspondent au meilleur cas possible pour la pile réseau ou la partie communication”, explique Karsten. “Si l’application fait principalement cela, on peut voir une amélioration de 30 %. Si l’application fait beaucoup d’autres choses et n’utilise le réseau qu’occasionnellement, ces 30 % se réduiront à une valeur bien plus faible.” »

• Cet article m’a rappelé de vieux souvenirs : https://didgets.substack.com/p/finding-and-fixing-a-billion-bug

[semanticist]

Oh~ c'est surprenant.

Ça fait aussi penser qu'il n'existe toujours pas de logiciel parfait.