powerd++ 0.4.4 release

[Kamikaze]

https://github.com/lonkamikaze/powerdxx/releases/tag/0.4.4

Gestern habe ich powerd++ 0.4.4 veröffentlicht. Der Anlass für das Release ist, dass sich mittlerweile viele Änderungen seit 0.4.3 angesammelt haben, die meisten dieser Änderungen sind zum Testen und Validieren, wie eine Sammlung von Load recordings zum Testen und Werkzeugen zur Analyse und Aufbereitung von Load replays. Aber es gibt auch Änderungen die für Nutzer relevant sind:

• Das -N Flag wurde von powerd(8) übernommen, es sorgt dafür dass Nice Last der Idle Zeit zugerechnet wird, ich persönlich halte die Funktion für Nutzlos da vor allem große, lang anhaltende nichtinteraktive Lasten wie kompilieren betrifft, was IMHO genau die Lasten sind für die man den Takt anheben will
• Statt in eine Assertion zu laufen verweigert powerd++ mit einer ordentlichen Fehlermeldung den Betrieb, wenn der CPU Takt via hwpstate Treiber durch die CPU gesteuert wird
• Die -t Option erlaubt das setzen eines eigenen sysctl als Temperaturquelle

Die eigentliche Funktionalität für -t waren nur eine Hand voll Zeilen Code aber da kam dann noch ein Eimer voll String Validierung, Fehlerbehandlung und besseres Highlighting von Fehleingaben.

 

[Crest]

Danke für diesen nützlichen Code.

 

[subcommandante]

https://github.com/lonkamikaze/powerdxx/releases/tag/0.4.4
Das -N Flag wurde von powerd(8) übernommen, es sorgt dafür dass Nice Last der Idle Zeit zugerechnet wird, ich persönlich halte die Funktion für Nutzlos da vor allem große, lang anhaltende nichtinteraktive Lasten wie kompilieren betrifft, was IMHO genau die Lasten sind für die man den Takt anheben will

Nein, nicht auf einer Maschine, die nah am Mensch ist (z.B. Laptop), wegen der Geräuschentwicklung. Mir ist doch egal ob kernel+world (+ggf. noch zig ports) 2 oder 5 Tage braucht. Aber ich will in der Zeit meine Ruhe haben.
Vielleicht findest Du meinen patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246940 nützlich. Es sollte umbenannt werden in: "wish/enhancement: expose additional cp_time(s) (realtime/user_idle) via new sysctl cp_time(s)_ext".
Einen vorläufigen patch für den powerd(8) in base habe ich am laufen,der das nutzt: dieses load wird einfach bei der Berechnung nicht mit aufaddiert. Rationale: ich lasse lange background tasks via idprio(8) laufen, und mein Laptop bleibt ruhig. Das wäre also ein zusätzlicher parameter -i oder -I (idle/nice+idle), damit diese Prozesse über ihr load nicht den CPU-Takt hochjagen.

 

[Kamikaze]

Wenn Du willst das Dein Rechner komme was wolle leise ist kannst Du doch einfach den maximalen Takt begrenzen. Wozu all der Aufwand?

 

[Kamikaze]

Wahrscheinlich wäre es sogar noch besser mit powerd++ thermisch zu Throtteln vor allem wenn Du weißt ab wann der Lüfter los läuft. Dann kann das Gerät immer noch kurzfristig hoch takten.

 

[Yamagi]

Für solche Dinge ist RAPL besser geeignet: https://01.org/blogs/2014/running-average-power-limit-–-rapl Auch, da powerd++ für alle Intel CPUs beginnend mit Skylake unnötig wird, sobald es hwpstate in ein Release schafft. Spätestens mit 13.0 wird es der Fall sein.

Es gibt nach wie vor kein fertiges Tool für FreeBSD, um RAPL zu konfigurieren. Aber man kann die MSR per cpucontrol manuell schreiben. Vielleicht ist das auch mal wieder eine gute Gelegenheit darauf hinzuweisen, dass ich bereits wäre https://github.com/Yamagi/powermon (implementiert nur die lesende Seite und es fehlen die letzten CPU-Generationen) in motivierte Hände zu übergeben, sollte jemand Interesse haben.

 

[subcommandante]

Wenn Du willst das Dein Rechner komme was wolle leise ist kannst Du doch einfach den maximalen Takt begrenzen. Wozu all der Aufwand?

Du gibst die Antwort selbst im folgenden Post: ich will ja nicht gänzlich verhindern, dass die CPU mal kurz hochfährt. Z.B. beim Surfen im Weltnetz, da will ich ja die Performance. Wenn der Lüfter ab- und an mal eine halbe Minute läuft, macht mir das nix. Aber stunden- oder sogar tagelang auf Volldampf? Das nervt. Daher finde ich die Idee vernünftig, lange laufende Tasks via idprio(1) laufen zu lassen (kann man auch als user: echo security.bsd.unprivileged_idprio=1 >>/etc/sysctl.conf) und diese Tasks bleiben bei der Berechnung des load unberücksichtigt, tragen also kaum (nur über ihre syscalls) zur Erhöhung des CPU-Taktes bei.