Startseite > Datacenter & Verkabelung > Energie in der Software

Infrastruktur

Energie in der Software

28. Oktober 2011, 10:51 Uhr | Carter Edmonds, Software Architect bei der Communications Rackmount Server Division von Kontron

Fortsetzung des Artikels von Teil 5

Linux-Power-Governor

Server benötigen eine Strategie, um das optimale Verhältnis zwischen Datenverarbeitungsleistung und Sleep-States zu erreichen, beispielsweise durch die Steuerung der P-States und C-States. Entsprechende Regelwerke sind in den so genannten Linux-Power-Governors implementiert, stellen aber zunächst einige nicht leicht zu beantwortende Fragen: Da Prozessoren bei hohen Taktraten viel Energie verbrauchen und im Schlafmodus wenig, ist es dann besser, eine Aufgabe schnell abzuschließen und so länger zu schlafen, oder ist es sinnvoller weniger zu schlafen aber im Betrieb durch eine reduzierte Taktrate weniger Energie zu verbrauchen?

Für einige Workloads ist es sinnvoll, dass der Prozessor sie so schnell wie möglich abarbeitet. Obwohl das mehr Energie benötigt, wird die Aufgabe schneller abgeschlossen und dann zum sparsamen C-State zurückgekehrt. Bei anderen Workloads kann es wiederum vorteilhafter sein, die CPU konstant bei niedriger Taktrate arbeiten zu lassen. Obwohl dafür ein Kern länger wach bleibt, benötigt dieser in der Summe weniger Energie für die Aufgabe.

Die Antwort ist also abhängig von der Workload, so dass Abstriche in Hinblick auf Durchsatz, Latenz und Energieverbrauch in Kauf genommen werden müssen. Drei Typen von Workloads sind zu unterscheiden: Prozessor-, Speicher- und I/O-abhängige. Prozessorabhängige Work-loads erzeugen kurze Lastspitzen, beispielsweise wenn neue Datenpakete einfließen und verarbeitet werden müssen. In diesen Fällen läuft der Prozessor bei hoher Taktrate, um den Arbeitsauftrag so schnell wie möglich abzuwickeln. Danach tritt er bis zur nächsten Lastspitze wieder in den Sleep-State ein, so dass die Sleep-Periode maximiert und der Energieverbrauch minimiert wird. Der „Linux on-demand Governor“ implementiert eben diese Verhaltensregel und ist die Grundeinstellung in den meisten Distributionen.

Abbildung 2 stellt eine Speicher-abhängige Applikationen dar und zeigt die Energieeinsparungen die durch die Wahl eines niedrigeren Power-States für eine bestimmte Workload erzielt wurde. Änderungen an der Prozessorfrequenz änderten das Bild nur leicht. Hingegen verbesserte die Vergrößerung des Chaches den Durchsatz deutlich. Letztendlich waren die Energieeinsparungen bei dieser Workload am größten, wenn der Prozessor bei geringst möglicher Taktrate arbeitete, da der Großteil der Verarbeitungszeit durch den Speichercontroller bestimmt wurde, der die Daten langsamer anliefert, als der Prozessor sie hätte verarbeiten können.

I/O-getriebene Telekommunikations-Applikationen stellen eine interessante Herausforderung dar. Wenn ein Thread durch ein eingehendes Datenpaket angestoßen wird, hängt die beste Strategie von der Frage ab, was mit dem Paket passieren soll? Soll das Paket mit einer im Speicher befindlichen Lookup-Tabelle verglichen werden, könnte der niedrig getaktete Prozessor die energieeffizientere Lösung darstellen, da die Ausführungsgeschwindigkeit vom Speicherdurchsatz abhängig ist. Mathematische Operationen auf dem Paket hingegen, profitieren insbesondere von höheren Taktraten. Bisher nicht in Erwägung gezogen wurde, wo sich der Cache befindet. In allen Fällen kann die optimale Lösung nur durch Evaluierung der Workload auf dem Ziel-system oder einem entsprechenden Simulator identifiziert werden. Außerdem ist die Energieeffizienz nur eines von mehreren Zielen und muss deshalb in Abhängigkeit von anderen Zielgrößen wie Quality-of-Service, Datendurchsatz und Latenz abgewogen werden.