12 Punkte von GN⁺ 2025-04-22 | 2 Kommentare | Auf WhatsApp teilen
  • Der Stromverbrauch von Rechenzentren in den USA lag 2023 bei rund 4 % des landesweiten Stromverbrauchs und soll bis 2028 auf 12 % steigen
  • Ein Forschungsteam der University of Waterloo hat durch eine Verbesserung der Netzwerkverarbeitung im Linux-Kernel eine Methode entwickelt, mit der sich der Stromverbrauch von Rechenzentren um bis zu 30 % senken lässt
  • Der Kern der Idee ist die dynamische Steuerung von Busy Polling, bei der je nach Verkehrslage automatisch zwischen Interrupt-Modus und Polling umgeschaltet wird
  • Diese Änderung wurde mit nur etwa 30 geänderten Codezeilen umgesetzt und ist offiziell in den Linux-6.13-Kernel eingeflossen
  • Sie hat breites Anwendungspotenzial für Linux-basierte Rechenzentren und Webserver und unterstreicht die Bedeutung einer an Effizienz orientierten Softwareentwicklung

Stromverbrauch von Rechenzentren: Mit nur 30 Zeilen Linux-Kernel-Code um bis zu 30 % senken

Sorge über den steigenden Energieverbrauch

  • Der Großteil des weltweiten Web-Traffics läuft über Rechenzentren, die die Grundlage für stromintensive Anwendungen wie AI-Services bilden
  • In den USA entfielen 2023 etwa 4 % des Stromverbrauchs auf Rechenzentren; bis 2028 soll der Anteil auf 12 % steigen

Der Kern des Problems: die Netzwerkverarbeitung im Linux-Kernel

  • Der Linux-Kernel nutzt bei der Verarbeitung von Netzwerkpaketen sowohl Interrupts als auch Polling
    • Interrupts: Trifft ein neues Paket ein, unterbricht die CPU ihre aktuelle Arbeit und verarbeitet es
    • Busy Polling: Zur Verringerung der Latenz wird regelmäßig geprüft, ob Pakete vorhanden sind – auch wenn keine anliegen → ineffizient

Die Lösung: Busy Polling dynamisch umschalten

  • Das Team um Professor Martin Karsten von der University of Waterloo schaltet abhängig vom Netzwerkverkehr um:
    • Bei hohem Traffic: Busy Polling verwenden
    • Bei geringem Traffic: auf den Interrupt-Modus umschalten
  • Das senkt unnötigen Stromverbrauch und erhöht die Flexibilität

Codeänderung und aktueller Stand der Einführung

  • In Zusammenarbeit mit dem Fastly-Ingenieur Joe Damato wurde dies durch eine Neuordnung des bestehenden Kernel-Codes umgesetzt
  • Statt neuen Code zu schreiben, wurde die bestehende Struktur angepasst, was Änderungen von nur rund 30 Zeilen erforderte
  • Offiziell enthalten im Linux-6.13-Kernel (veröffentlicht im Januar 2025)
    Kernel-Commit

Wirkung auf den Energieverbrauch

  • Bei netzwerkzentrierten Anwendungen sind Stromeinsparungen von bis zu 30 % möglich
    • Bei allgemeinen Anwendungen kann die Einsparquote geringer ausfallen
  • Da sich das System automatisch an Traffic-Änderungen anpasst, ist es besonders für Rechenzentren geeignet
  • Auch auf Linux-basierte Webserver wie nginx und Apache übertragbar

Verbreitung in der Community und Einfluss auf Open Source

  • Damato plant, die Technik auch auf den H2O-Server von Fastly anzuwenden
  • Da es sich um Open-Source-Kernel-Code handelt, können sich auch andere Webserver-Entwickler daran orientieren
  • Es wird erwartet, dass dies als Impuls für die Wiederbelebung einer auf Energieeffizienz ausgerichteten Entwicklungskultur dient

Die philosophische Bedeutung der Forschung

  • „In den 90er-Jahren war Ressourcenoptimierung ein Grundprinzip der Informatik“, doch in den vergangenen 20 Jahren habe sich der Fokus zu stark auf Leistung verlagert, während Effizienz vernachlässigt wurde
  • Diese Forschung zeigt, dass kleine Codeverbesserungen zu enormen Energieeinsparungen führen können, und weist damit auf eine Richtung für nachhaltige Softwareentwicklung hin

2 Kommentare

 
GN⁺ 2025-04-22
Hacker-News-Kommentare
  • Linux hat eine Busy-Polling-Funktion für High-Performance-Networking hinzugefügt. Die meiste Linux-Software nutzt sie nicht, aber Software, die in Rechenzentren eingesetzt wird, ist energetisch ineffizient, wenn das System nicht ausgelastet ist. Dieser Patch ermöglicht es, sie abzuschalten, wenn das System nicht ausgelastet ist, und so die Energieeffizienz wiederherzustellen.

    • Der Artikeltitel ist etwas irreführend. Er klingt so, als würde das auch für Desktop-Workloads gelten, tatsächlich ist es aber für Rechenzentren gedacht. Hätte man im Titel "in datacenters" ergänzt, wäre die Verwirrung vermeidbar gewesen.
  • Ein großer Teil der High-Performance-Workloads in Rechenzentren läuft in Wirklichkeit gar nicht durch den Netzwerk-Stack des Linux-Kernels.

    • Stattdessen werden DPDK, XDP oder User-Space-Stacks wie Onload oder VMA verwendet. Oft übernehmen SmartNICs das Hardware-Offloading. In solchen Fällen ist dieser Patch nicht anwendbar.
    • Dennoch hilft dieser Patch eindeutig bei Setups, in denen der Kernel im Datenpfad liegt (CDNs, Ingress-Nodes, VMs, eingebettete Linux-Systeme usw.). Bei Workloads, die den Kernel aus Performance- oder Latenzgründen bereits umgehen, wird er kaum Auswirkungen haben. Die Schlagzeile mit 30% Stromersparnis ist stark situationsabhängig.
  • Mehr Details zu dieser Änderung gibt es unter https://lwn.net/Articles/1008399/.

  • Wirklich eine großartige Änderung. Als Experte für High-Performance-Computing frage ich mich oft, wie viel Energie durch ineffizienten Code verschwendet wird und wie groß dieses Problem wird, während planetare Rechenleistung weiter skaliert.

    • Ich persönlich empfinde eine moralische Verpflichtung, Code so effizient wie möglich zu schreiben. Besonders dann, wenn ein Job monatelang auf Hunderten von CPUs läuft.
  • Umgekehrt hat Meta einen Hack, um GPUs beschäftigt zu halten, damit der Stromverbrauch beim LLM-Training konstanter bleibt. Zum Beispiel will man bei der Batch-Synchronisierung keinen großen Leistungseinbruch.

  • Bedeutet das, dass "adaptive interrupt mitigation" im Kernel nicht mehr verwendet wird? Ich habe seit mehr als etwa 15 Jahren nicht mehr an etwas in diesem Bereich gearbeitet, aber der Kernel passte sich früher so an, dass bei niedrigen Netzwerkgeschwindigkeiten Interrupts verwendet wurden und ab einem bestimmten Punkt die Interrupts abgeschaltet und Polling genutzt wurde.

    • Das Problem, das man zu lösen versuchte, waren plötzliche und drastische Traffic-Änderungen. Zum Beispiel, wenn im Switching ein Loop eingeführt wird und der entsprechende Packet Storm entsteht. In diesem Fall kamen die Interrupts so schnell, dass das System nicht genug nicht-interruptgesteuerte Zeit bekam, um die Interrupts selbst deaktivieren zu können. Deshalb bestand die Lösung darin, dafür zu sorgen, dass ein Linux-Router mehr Kerne als Netzwerkschnittstellen hat.
  • Wenn in einem Satz "Up To" vorkommt, ist wörtlich alles möglich.

  • Nicht direkt zum Thema, aber ich freue mich, wieder etwas über Joe Damato zu lesen. Das weckt Erinnerungen. Nachdem ich damals erstmals James Golicks Artikel über tcmalloc gelesen und dadurch packagecloud.io kennengelernt hatte, stieß ich auf Joes großartige Beiträge.

  • Der zentrale Absatz:

    • "Bei dieser Energieeinsparung gibt es einen wichtigen Vorbehalt. 'Die 30% sind der Best-Case für den Netzwerk-Stack oder den Kommunikationsteil', erklärt Karsten. 'Wenn die Anwendung hauptsächlich genau das macht, kann man eine Verbesserung von 30% sehen. Wenn die Anwendung viele andere Dinge tut und das Netzwerk nur gelegentlich nutzt, schrumpfen die 30% auf einen kleineren Wert.'"
  • Dieser Artikel ruft Erinnerungen wach: https://didgets.substack.com/p/finding-and-fixing-a-billion-bug

 
semanticist 27 일 전

Oh, wie interessant.
Da denkt man auch wieder, dass es wohl doch noch keine perfekte Software gibt.