CPU – Linux und Ich

Mit dem PHC-Kernel unter Ubuntu Karmic Strom sparen

Christoph Langner — Wed, 04 Nov 2009 16:16:27 +0000

Mein kleines Notebook hier hat mit Linux leider ein kleines Problemchen. Bei jeder noch so kleinen Belastung der CPU, dreht der Lüfter sofort hoch. Selbst das Aufrufen einer Webseite mit Firefox sorgt somit für Lärm im Raum. Die Lösung dafür war schon immer das Absenken der CPU-Spannung durch das Patchen eines Kernel-Moduls. Dadurch läuft das Gerät praktisch geräuschlos.

Nun baut Ubuntu jedoch seit Jaunty die dafür nötigen Kernel-Module fest in den Kernel ein. Dadurch ist es nicht mehr möglich nur das eine Kernel-Module zu patchen, es muss leider der gesamte Kernel neu kompiliert werden… Vor einigen Monaten habe ich bereits über eine Paketquelle mit einem „PHC-Kernel“ geschrieben, in der Hoffnung dass mit der Quelle die Kernel-Kompiliererei ein Ende hat, doch bislang war ich vom linux-phc Team etwas enttäuscht. Das PPA hat meiner Erinnerung nach, während der bisherigen Lebenszeit von Jaunty gerade mal ein Update erfahren.

Mit Ubuntu Karmic ändert sich das Vorgehen mal wieder etwas. Das PPA enthält nun einen Kernel, der die SpeedStep-Module komplett fehlen, so kann man sich die Kernelmodule selber erzeugen…

PHC-Kernel installieren

Den Anfang macht die Installation des angepassten Kernels, man kann den Kernel sowie die nötigen Bibliotheken und Tools für das Kompilieren des Kernelmoduls via…

$ sudo add-apt-repository ppa:linux-phc/ppa
$ sudo apt-get install build-essential linux-generic-phc linux-headers-generic-phc

…herunterladen und installieren. Nach der Installation startet man am besten den Rechner neu. Beim Booten steht jetzt ein zusätzlicher Kernel, der mit -phc endet, zur Verfügung. Speed-Stepping sollte mit diesem Kernel erstmal nicht funktionieren, wundert Euch also nicht wenn die CPU vorerst immer mit maximaler Taktrate läuft.

Kernelmodule erzeugen

Nun könnt Ihr euch aus dem Forum von linux-phc.org bereits gepatchte Kernelmodule herunterladen. Es gibt zwei Varianten, einmal phc-k8*.tar.gz für AMD X2, AMD Turion64 und AMD Turion X2 Prozessoren und einmal phc-intel*.tar.gz für Intel Mobile Centrino, Atom (N2xx) und Intel Core/Core2 CPUs. Ihr müsst das passende Kernelmodul wählen.

Ich habe hier ein Gerät mit einem alten Intel Centrino, daher führe ich das am Beispiel des gerade aktuellen Moduls phc-intel-0.3.2-8.tar.gz durch… Habt Ihr das Modul heruntergeladen, so müsst Ihr es entpacken und in das entstandene Verzeichnis wechseln…

$ tar -xzf phc-intel*
$ cd phc-intel*

Nun könnt ihr das Modul erzeugen, kompilieren und installieren. Dies könnt Ihr via…

$ make prepare
$ make
$ sudo make install
$ sudo modprobe phc-intel

…durchführen. Solltet ihr Schwierigkeiten dabei haben, so liefert die im Archiv enthaltene README Datei weitere Informationen. Den Erfolg könnt Ihr wieder via…

$ cat /sys/devices/system/cpu/cpu0/cpufreq/phc_controls
16:33 14:33 12:20 10:14 8:6 6:4

…ausprobieren. Ist das Modul erfolgreich gebaut worden und habt Ihr es via modprobe geladen, dann zeigt die Ausgabe von cat etwas an, falls die Ausgabe nichts bringt, dann hakt es irgendwo. Damit das Kernelmodul von nun an automatisch geladen wird, steckt ihr es in die Datei /etc/modules. Öffnet dazu die Datei in einen Editor mit Root-Rechten…

$ sudo gedit /etc/modules

und fügt die Zeile…

phc-intel

…ein. Speichert die Datei abschließend. Ihr seid damit noch nicht fertig… Ihr müsst noch passende Spannungswerte ermitteln und die Einstellungen permanent in Eurem System verankern. Seit Jaunty hat sich das Vorgehen nicht verändert. Informationen dazu findet Ihr im älteren Artikel PPA für Jaunty mit gepatchtem Kernel zum Undervolten.

Governor ohne PolicyKit-Abfrage ändern

Abschließend noch ein kleiner Tipp, der mit dem Thema hier nicht direkt etwas zu tun hat. In den Kommentaren zu Ubuntu Karmic Koala 9.10 aus meiner Sicht hat Christoph Wickert Hinweise gegeben, wie man auch mit PolicyKit-1 von GNOME aus Karmic die Taktrate bzw. den Governor ohne Passwortabfrage ändern kann. Ich füge dazu alle Benutzer, die den Governor ändern können sollen, in die Gruppe „users“ ein…

$ sudo adduser $USER users

(Kleiner Hinweis: Ihr müsst euch einmal aus und wieder einloggen. Erst dann werden die Gruppenzugehörigkeiten neu eingelesen) Danach könnt Ihr via…

$ sudo gedit /var/lib/polkit-1/localauthority/50-local.d/gnome-cpufreq.pkla

…die nötige Konfigurationsdatei erstellen. Als Inhalt fügt Ihr…

[Allow users to set the CPU frequency]
Identity=unix-group:users
Action=org.gnome.cpufreqselector
ResultAny=no
ResultInactive=no
ResultActive=yes

…ein. Danach könnt Ihr die Taktrate ohne die Eingabe eines Passwortes ändern.

Powersave heißt nicht Energie sparen

Christoph Langner — Wed, 10 Jun 2009 11:50:04 +0000

Arbeitet man mit einem Notebook unterwegs, so will man die maximale Akkulaufzeit aus dem Gerät herauspressen. Ein beliebter „Trick“ ist die Taktrate der CPU auf ein Minimum herabzusetzen. Bei niedrigeren Taktraten wird die CPU mit weniger Spannung versorgt und nimmt so weniger Leistung auf, so der Glaube. Das ist zwar korrekt, doch leider ist es nur die halbe Wahrheit…

Dazu gibt es in GNOME das CPU Frequency Applet, das den Benutzer durch die Option „Powersave“ schnell dazu verleitet diese Einstellung im mobilen Betrieb zu verwenden. Öfters liest man Support-Anfragen in dieser Art…

Ich würde gerne mein Ubuntu 9.04, das auf einem Notebook läuft, so konfigurieren, dass es die CPU-Policy auf „Powersave“ stellt, wenn es per Akku betrieben wird und auf „OnDemand“ schaltet, wenn es an der Steckdose hängt.

Wie Eingangs angesprochen ist die Taktrate der CPU nur ein kleines Zahnrad im Räderwerk des Energiemanagements einer CPU. Viel wichtiger sind die Schlafmodi der CPU, in die ein Prozessor jedoch nur fallen kann, wenn es nichts mehr zu tun gibt. Im Normalfall (d.h. „normaler“ Betrieb: Keine Spiele, keine andauernden Berechnungen) spart man mit „Powersave“ KEINE Energie. Auch wenn diese Option fälschlicherweise „Powersave“ heißt, der Akku geht damit eher schneller zur neige.

Das GNOME Frequency Applet zur Steuerung der Taktraten

Ich zitiere mal Making sure we do power management the right way von Matthew Garrett. Matthew ist ein Angestellter von Canonical und dort unter Anderem für den Kernel zuständig.

Original	Übersetzung
To a first approximation, the Powersave governor will only save you power if you’re playing 3D games. The performance governor will basically never give you extra performance. Don’t use them. Use ondemand instead. Do not make it easy for your users to choose them. They will get it wrong, because it is difficult to explain why this result is true.	Der Powersave-Regler wird nur Energie sparen, wenn du 3D Spiele spielst. Der Performance-Regler wird dir praktisch nie extra Leistung liefern. Verwende diese Einstellungen nicht. Du solltest „ondemand“ verwenden. […] Entwickler sollten es vermeiden diese Optionen zur Auswahl anzubiten, da Enduser diese Begriffe falsch interpretieren werden.

Weitere Informationen und ein anschauliches Beispiel gibt Arjan van de Ven, der Kopf eines Teams bei Intel, das sich um Power Management und die Performance von Linux auf Intel Hardware kümmert.

Original	Übersetzung
it’s a bit complex to explain, but it’s better to execute the code you need to execute at full speed, and then really quickly go idle, than it is to execute at a much lower speed. Maybe a simple example (I plucked these numbers out of the air, they don’t represent any real cpu that exists) will help: Say you have a cpu that consumes 40 Watts at full speed, and 30 Watts at half speed, and 4 Watts when idle. You have something to do, lets say mp3 decoding of 1 second of audio, and that takes a full second at half speed, and one second at full speed. At full speed decode + idle, that is half a second at 40 watts (20 Joules) and half a second at 4 Watts (2 Joules); total is 22 Joules. At half speed decode, that is a full second at 30 Watts, so 30 Joules. So, what ondemand does would cost 22 Joules, while a „hit the exact frequency“ governer would cost you 30 Joules…..	Es ist schwierig zu erklären, aber es ist besser ein Code bei voller Taktrate auszuführen und dann schnell in den Leerlauf zu fallen, als den selben Code bei einer viel niedrigen Taktrate auszuführen. Vielleicht verdeutlicht ein einfaches Beispiel den Zusammenhang (Die Zahlen repräsentieren keine reale CPU, sie sind aus der Luft gegriffen): Angenommen man hat eine CPU, die 40 Watt bei voller Taktrate, 30 Watt bei halber und 4 Watt im Leerlauf benötigt. Nun lässt man den Rechner arbeiten, beispielsweise decodiert man eine MP3-Datei mit einer Länge von einer Sekunde. Dies dauert bei halber Taktrate eine ganze Sekunde und eine halbe Sekunde bei voller Taktrate [Anmerkung: Hier hat sich der Autor wohl vertippt]. Bei voller Geschwindigkeit benötigt dieser Vorgang 22 Joules (0,5 Sekunden bei 40 Watt und 0,5 Sekunden bei 4 Watt), drosselt man nun die CPU und decodiert bei halber Taktrate dauert der Vorgang eine ganze Sekunde bei 30 Watt, so dass 30 Joules Energie benötigt werden. Ondemand benötigt also 22 Joules, während der „Benutze nur diese eine Taktrate“-Regler dich 30 Jules kosten würde.

Original

Übersetzung

it’s a bit complex to explain, but it’s better to execute the code you need to execute at full speed, and then really quickly go idle, than it is to execute at a much lower speed.

Maybe a simple example (I plucked these numbers out of the air, they don’t represent any real cpu that exists) will help: Say you have a cpu that consumes 40 Watts at full speed, and 30 Watts at half speed, and 4 Watts when idle. You have something to do, lets say mp3 decoding of 1 second of audio, and that takes a full second at half speed, and one second at full speed.

At full speed decode + idle, that is half a second at 40 watts (20 Joules) and half a second at 4 Watts (2 Joules); total is 22 Joules. At half speed decode, that is a full second at 30 Watts, so 30 Joules.

So, what ondemand does would cost 22 Joules, while a „hit the exact frequency“ governer would cost you 30 Joules…..

Es ist schwierig zu erklären, aber es ist besser ein Code bei voller Taktrate auszuführen und dann schnell in den Leerlauf zu fallen, als den selben Code bei einer viel niedrigen Taktrate auszuführen.

Vielleicht verdeutlicht ein einfaches Beispiel den Zusammenhang (Die Zahlen repräsentieren keine reale CPU, sie sind aus der Luft gegriffen): Angenommen man hat eine CPU, die 40 Watt bei voller Taktrate, 30 Watt bei halber und 4 Watt im Leerlauf benötigt. Nun lässt man den Rechner arbeiten, beispielsweise decodiert man eine MP3-Datei mit einer Länge von einer Sekunde. Dies dauert bei halber Taktrate eine ganze Sekunde und eine halbe Sekunde bei voller Taktrate [Anmerkung: Hier hat sich der Autor wohl vertippt].

Bei voller Geschwindigkeit benötigt dieser Vorgang 22 Joules (0,5 Sekunden bei 40 Watt und 0,5 Sekunden bei 4 Watt), drosselt man nun die CPU und decodiert bei halber Taktrate dauert der Vorgang eine ganze Sekunde bei 30 Watt, so dass 30 Joules Energie benötigt werden. Ondemand benötigt also 22 Joules, während der „Benutze nur diese eine Taktrate“-Regler dich 30 Jules kosten würde.

Will heißen, je schneller die CPU wieder in Tiefschlaf fallen kann, desto mehr Energie wird sie sparen. Indem man sie nun zwingt immer mit niedrigster CPU-Rate zu laufen, verhindert man dass sie möglichst schnell wieder Einschlafen kann. Mit Powersave spart man nur dann Energie, wenn die CPU sowieso bei jeder Taktrate voll ausgelastet wäre (also bspw. bei 3D-Spielen oder Berechnungen). Im normalen Betrieb, egal ob Akku oder Netz, sollte man OnDemand benutzen um Energie zu sparen.

Ich persönlich benutze Powersave um den Lärm, den der Lüfter meines Laptops macht, zu kontrollieren. Arbeitet man mit Anderen in einer leisen Umgebung, so ist ein permanent hochdrehender Lüfter doch arg nervig. Weitere interessante Ideen bzgl. Energiesparen bei Computern im Allgemeinen und Laptops im Speziellen findet man auf thinkpad-wiki.org unter Linux Stromsparen und Vista Stromverbrauch senken.