# Acpi - Verständnisfrage

## industrie13

Hi,

wie ich die Sache sehe, lässt sich das Powermanagement auf 2 Wegen lösen:

1. ich wähle beim Kernelbauen einen Gouvernor, z.B. 'ondemand' aus und kompilier ihn fest ein, so dass er quasi alles Acpi-relevante erledigt

2. ich lasse die Acpiverwaltung im Userspace laufen & von einem Daemon wie z.B. powersaved oder powernowd regeln

Was ich jetzt noch nicht wirklich geblickt habe, ist, wo konkret die Vorteile der beiden Varianten liegen. Ich meine, ob ich den Kernelgouvernor mit 'ondemand' wähle, oder bei powersaved 'ondemand' - letztendlich sollte doch bei beiden das gleiche rauskommen, oder?

Ok, bei letzterem bin ich etwas flexibler und könnte die Acpieinstellungen zur Laufzeit ändern ... aber macht das jemand, gibts dafür sinnvolle Szenarien?

----------

## misterjack

ACPI hat mit 'ondemand' etc soviel zu tun, wie Äpfel mit Birnen. Lesetipps: Advanced Configuration and Power Interface und Cool’n’Quiet oder Intel-SpeedStep-Technologie.

Ich denke in Bezug auf deinen Post, dass 1. mit 2. nichts zu tun hat. Bitte stelle dann deine Fragen erneut nach Sichtung der empfohlenen Lektüre.

----------

## industrie13

ACPI  dreht sich, auch laut dem tollen Wiki-Artikel, um die Energieverwaltung. 

Und diese wiederum bietet die Möglichkeit, Takt und Kernspannung der CPU zu drosseln - um eben Energie zu sparen.

Wann und ob das geschieht, legt meines Verständnisses nach der Gouvernor fest ... wobei 'ondemand' auch nix anderes heißt, als dass Takt & Kernspannung eben bei wenig Auslastung abgesenkt und bei Auslastung wieder angehoben werden.

Die Wahl des Gouvernors beeinflusst dieses Verhalten nicht unwesentlich.

Ich weiß jetzt nicht genau, worauf du hinaus willst - die Steuerung des CPU-Taktes ist ein Teilaspekt von ACPI und somit von ihm nicht vollkommen verschieden davon.

Aber darum ging es in meiner Frage ja auch gar nicht. Ich wollte wissen, welche Vor- und Nachteile es hat, den Gouvernor im Kernel oder im Userspace laufen zu lassen bzw. wie ein sinnvolles Anwendungsszenario für letzteres aussehen könnte.

----------

## STiGMaTa_ch

 *industrie13 wrote:*   

> Hi,
> 
> wie ich die Sache sehe, lässt sich das Powermanagement auf 2 Wegen lösen:

 

Korrekter Anfang...

 *industrie13 wrote:*   

> 1. ich wähle beim Kernelbauen einen Gouvernor, z.B. 'ondemand' aus und kompilier ihn fest ein, so dass er quasi alles Acpi-relevante erledigt
> 
> 2. ich lasse die Acpiverwaltung im Userspace laufen & von einem Daemon wie z.B. powersaved oder powernowd regeln

 

...falsche Schlussfolgerung. Powermanagement lässt sich tatsächlich über zwei Wege realisieren. ACPI oder APM. Allerdings hat ACPI und CPU frequency scaling (was du mit deinen Gouvernors beschreibst) rein gar nichts miteinander zu tun. CPU frequency scaling ist ein Feature deiner CPU und funktioniert unabhängig von ACPI. Das siehst du schon daran, dass du im Kernel Power Management deaktivieren kannst und trotzdem noch die Settings für das CPU scaling zur Verfügung hast.

 *industrie13 wrote:*   

> Was ich jetzt noch nicht wirklich geblickt habe, ist, wo konkret die Vorteile der beiden Varianten liegen. Ich meine, ob ich den Kernelgouvernor mit 'ondemand' wähle, oder bei powersaved 'ondemand' - letztendlich sollte doch bei beiden das gleiche rauskommen, oder?

 

Im Endeffekt schon. Ja. Aber du vergisst, dass es nunmal nicht nur die Consumer x86 Systeme gibt. Da wären z.B. noch ARM, PPC, SPARC oder superH Prozessoren, welche das CPU frequency scaling ebenfalls anbieten. Einige dieser Prozessoren wechseln dynamisch und unabhängig vom Kernel die Frequenzen. Das einzige was du dort noch "bewirken" kannst sind Aggressivität der Einstellungen oder zu verwendende Ober- bzw. Untergrenzen für die Frequenz. Bei anderen Prozessoren wiederum kannst/musst du alles selber im Userspace lösen. Daher gibt es diese beiden Möglichkeiten.

Der Unterschied zwischen ondemand und userspace ist lediglich der, dass ondemand selber entscheidet ob er "regeln" soll oder nicht, wohingegen beim userspace DU (resp deine Settings für die entsprechende Software) entscheidest. Die Userspace Möglichkeit brauchst du spätestens dann, wenn du sicherstellen willst, dass z.B. dein Laptop während des Strombetriebes immer mit voller Leistung läuft, jedoch im Akku Betrieb dynamisch skaliert. 

 *industrie13 wrote:*   

> Ok, bei letzterem bin ich etwas flexibler und könnte die Acpieinstellungen zur Laufzeit ändern ... aber macht das jemand, gibts dafür sinnvolle Szenarien?

 

ACPI Einstellungen kannst du keine verändern. ACPI schickt events auf welche du reagieren kannst (oder auch nicht).

Lieber Gruss

STiGMaTa

----------

## STiGMaTa_ch

 *industrie13 wrote:*   

> ACPI  dreht sich, auch laut dem tollen Wiki-Artikel, um die Energieverwaltung. 
> 
> Und diese wiederum bietet die Möglichkeit, Takt und Kernspannung der CPU zu drosseln - um eben Energie zu sparen.

 

Das stimmt schon. Allerdings versteht man da nicht das heruntertakten von 1500MHz auf 500Mhz sondern das umschalten diverser Systemzustände welche mit deiner CPU rein gar nichts zu tun haben müssen. So beschreibt der S4 Modus den Ruhezustand (Hibernation) welcher dein System dazu bringen soll alle RAM Inhalte in ein Image auf Disk zu dumpen und dann die Maschine auszuschalten. Da wird die CPU weder getaktet noch gethrottelt.

 *industrie13 wrote:*   

> Ich weiß jetzt nicht genau, worauf du hinaus willst - die Steuerung des CPU-Taktes ist ein Teilaspekt von ACPI und somit von ihm nicht vollkommen verschieden davon.

 

Siehe oben und letzter Post.

Lieber Gruss

STiGMaTa

----------

## bell

Ich kenne zwar jetzt die Theorie nicht dazu, jedoch praktische Erfahrungen.

Auf meinem Laptop habe ich den kernel ondemand frequenz scaling genutzt. Sehr praktisch, da keine Zusatzsoftware oder Konfiguration benötigt wird. Ein Paar Eistellungen kann man unter /sys/??? machen. Ein echo [ondemand|poversave|performance] > /sys/???/gouvernor?? reicht zum Umschalten zwischen "sparsam","bei Bedarf" und "Vollgas". "ondemand" hat im Vergleich mit "performance" fast die gleiche Leistung, da bei Last der Prozessor auch auf voller Leistung ist.

Auf meinem PC, mit NForce2/AthlonXP fand ich eine indirekte Möglichkeit die CPU-Frequenz zu steuern, und zwar mit Änderung des FSB-Taktes (CPUFREQ_NFORCE2). Diese wollte aber nicht mit den Kernel-Governors zusammenarbeiten, so dass ich auf die Userspace-Tools ausweichen musste. Damit hatte ich dann under/overclocking on-demand realisiert. Allerdings lief es bei mir nicht stabil und ich hatte nicht die Zeit dazu, rauszufinden bei welcher Frequenz welche Prozessor-Spannung am besten geeignet ist. Also gab ich es auf.

Hoffe das beantwortet ein Paar deiner Fragen.

----------

## industrie13

Aah, ok ... jetzt kommt etwas Licht in die Sache  :Smile: .

 *STiGMaTa_ch wrote:*   

>  *industrie13 wrote:*   ACPI  dreht sich, auch laut dem tollen Wiki-Artikel, um die Energieverwaltung. 
> 
> Und diese wiederum bietet die Möglichkeit, Takt und Kernspannung der CPU zu drosseln - um eben Energie zu sparen. 
> 
> Das stimmt schon. Allerdings versteht man da nicht das heruntertakten von 1500MHz auf 500Mhz sondern das umschalten diverser Systemzustände welche mit deiner CPU rein gar nichts zu tun haben müssen. So beschreibt der S4 Modus den Ruhezustand (Hibernation) welcher dein System dazu bringen soll alle RAM Inhalte in ein Image auf Disk zu dumpen und dann die Maschine auszuschalten. Da wird die CPU weder getaktet noch gethrottelt.

 

Laut dem von misterjack geposteten Wiki-Artikel zu ACPI gibt es neben den Schlafmodi ja auch noch weitere Zustände und "Unterzustände" (wenn ich das mal so ausdrücken darf), so auch diese sog. Performance-States als Unterzustände von C0 (Arbeitszustand). An genau dieser Stelle wurde dort eben auch die Drosselung von Kernspannung und Takt angesprochen - ist das nicht mit CPUFreq-Scaling gleichzusetzen?

Es klang für mich so, als wären diese ganzen Zustandsbeschreibungen, also auch die Performance-States, Teil des ACPI-Standards.

 *Wiki wrote:*   

> Prozessoren können sich innerhalb des G0-Zustands in verschiedenen Unterzuständen befinden. C0 ist dabei der „Arbeitszustand“. Jeder ACPI-fähige Prozessor beherrscht darüber hinaus den C1-Zustand, der aktiviert wird, wenn der Prozessor leerläuft. Dabei wird dem Prozessor die hlt-Instruktion gesendet. Sobald ein Interrupt anliegt, wacht er wieder auf. Besonders Mobilprozessoren kennen darüber hinaus noch die stärkeren Sparzustände C2, C3 oder noch höher, bei denen das Aufwachen zunehmend länger dauert (bei C3 meist bereits so viel, dass es sich nicht lohnt, diesen Zustand einzusteuern, da der Weg zurück nach C0 zuviel Zeit benötigt). In den C-Zuständen geht es zunächst nur um leerlaufende Prozessoren. Darüber hinaus können viele moderne CPUs bei wenig Arbeitsaufkommen in C0-Takt und Kernspannung mehrstufig drosseln. Von diesen „Performance States“ (P-States) kann es beliebig viele geben. Das Betriebssystem muss entscheiden, wie stark es den Prozessor bei niedrigem Arbeitsaufkommen drosselt, ohne dass eine Rückkehr zur höchsten Taktstufe P0 unangemessen lange dauert.

 

----------

## industrie13

 *bell wrote:*   

> Hoffe das beantwortet ein Paar deiner Fragen.

 

Na es gibt mir zumindest ein Beispiel  :Wink: .

Hintergrund war bei mir, dass ich das CPU-Frequenzscaling bisher immer mit (k)powersaved geregelt hab. Das hatte ich bisher eh' immer auf ondemand gelassen und auch sonst nie irgendwelche ACPI-Ereignisse konfiguriert habe und bin damit auch ganz gut gefahren.

Beim Neubauen des Kernels vor kurzem hab ich mich dann gefragt, ob ich mir den Daemon nicht theoretisch auch sparen und das alles vom Kernel erledigen lassen könnte - daher meine Frage  :Wink: .

----------

## firefly

 *industrie13 wrote:*   

>  *bell wrote:*   Hoffe das beantwortet ein Paar deiner Fragen. 
> 
> Na es gibt mir zumindest ein Beispiel .
> 
> Hintergrund war bei mir, dass ich das CPU-Frequenzscaling bisher immer mit (k)powersaved geregelt hab. Das hatte ich bisher eh' immer auf ondemand gelassen und auch sonst nie irgendwelche ACPI-Ereignisse konfiguriert habe und bin damit auch ganz gut gefahren.
> ...

 

eventuell macht powersaved auch nicht anderes als den gouvernor zu ändern.

----------

## STiGMaTa_ch

 *industrie13 wrote:*   

> Laut dem von misterjack geposteten Wiki-Artikel zu ACPI gibt es neben den Schlafmodi ja auch noch weitere Zustände und "Unterzustände" (wenn ich das mal so ausdrücken darf), so auch diese sog. Performance-States als Unterzustände von C0 (Arbeitszustand). An genau dieser Stelle wurde dort eben auch die Drosselung von Kernspannung und Takt angesprochen - ist das nicht mit CPUFreq-Scaling gleichzusetzen?

 

Nein. ACPI drosselt gar nichts. ACPI ist nur eine Schnittstelle, welche irgendwelche States setzt und Events erzeugt, auf die irgendwas (hoffentlich) horcht. Dieser Dienst oder dieses Programm muss dann entweder durch interne Mechanismen oder Scripts oder was auch immer irgendwas anstossen (z.B. HD in Standby schicken, in /sys scaling_setspeed setzen etc.).

Wenn du im Kernel ACPI deaktivierst und Governoring verwendest, dann wird sich die CPU Frequenz trotzdem verändern lassen. Auf einem Desktop Rechner mag dir das wahrscheinlich schon genügen. Denn vielmehr kann man dort oftmals auch nicht anstellen. Wenn du aber einen Laptop verwendest, dann willst du Governor auch zusammen mit ACPI verwenden. Denn dadurch kann deine CPU selber auch ACPI Events erzeugen, auf die das Betriebsystem sowie andere Komponenten reagieren können.

Hier mal ein Beispiel von meinem Laptop

 *Quote:*   

> Mar 29 19:08:04 [acpid] received event "processor CPU0 00000080 0000000d"
> 
> Mar 29 19:08:18 [acpid] received event "processor CPU0 00000080 00000008"
> 
> Mar 29 19:20:21 [acpid] received event "processor CPU0 00000080 0000000d"
> ...

 

Lange Rede kurzer Sinn: ACPI und CPU Frequency Scaling sind zwei völlig voneinander unabhängige Komponenten. Im Zusammenspiel entfalten diese beiden Komponenten aber - besonders auf Laptops - erst deren wahres Potenzial.

Lieber Gruss

STiGMaTa

----------

