# Power management: how it works?

## vodkin40

I am trying to understand how exactly power management works in 2.6 kernel. I read HOWTO but some things are still confusing.  

Here are my findings and questions. 

- ACPI manages hardware and events

- default processor driver knows how to switch volatage/frequency and registers itself as default ACPI power governor - am I right?. This is confusing a little bit, because when I unplugged my laptop, frequency dropped but  scaling governor (/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor) is still set to "performance"

- it brings another question: from power management HOWTO, I understand that I need to install cpufreq daemon (eg speedfreq) if I want advanced cpu control. But will default processor driver react to AC plug/unplug and adjust frequency without cpufreq daemon?

- I have acpid installed and I can write event scripts. klaptop from KDE has its own settings and utilities for power management.  Is there a connection between my scripts and klaptop settings?

Thanks in advance for any help and advice

----------

## Sgeorg

it's quite easy:

performance governor only means set current speed to currently set maximum

powersave governor in the contrarry means set current speed to currently set minimum.

userspace means: set speed as user defined but only within the min and max range (also user defined)

there is no processor driver, there is only a speedstepp powernow and so on driver which interfaces the hardware to bring up a common interface to the user (/sys/devices.........)

and this has nothing todo with the governor, the governor is only a profile or a mode (some kind of).

e.g. cpudynd isn't aware of the power situation of your laptop, you have to do this by your own. but cpufreqd is aware of the battery status since it polls /proc/acpi/battery/BAT#/state constanly for battery status.

as I know (and I really think I now, but prove me wrong)  there is no connection between klaptop and acpid and it's scripts.

Georg

----------

## Flintz

Ok guys I have a little problem. As I switched from KDE to fluxbox, I decided to let cpufreqd set my cpu speed instead of klaptop (BTW klaptop worked without ANY problems!!!). So I emerged it and tried to start it, but it said:

CPUFreq support has not been compiled into kernel

So I looked into /sys/devices/system/cpu/cpu0/ and the directory is EMPTY, not cpufreq in it...

A little snapshot from my kernel config:

 *Quote:*   

> 
> 
> #
> 
> # CPU Frequency scaling
> ...

 

lspci brings up this:

 *Quote:*   

> 
> 
> 0000:00:00.0 Host bridge: Intel Corp. 82440MX Host Bridge (rev 01)
> 
> 0000:00:00.1 Multimedia audio controller: Intel Corp. 82440MX AC'97 Audio Controller
> ...

 

an lsmod this:

 *Quote:*   

> 
> 
> Module                  Size  Used by
> 
> prism54                49692  0
> ...

 

Honestly, I have no idea why this won't work :-/

CPU is a Intel Pentium III Mobile 750 Mhz, chipset can been seen above.

I would really like to use CPUFREQD as the options fit my needs perfectly (yes, yes I know there are also some other programs...)

Any help is apreciated!

----------

## Flintz

Ok, I got Speedstep working...at least somehow. I had to compile the Speedstep support as a module and load it with "modprobe speedstep-smi smi_port=0xb2 smi_cmd=0x82 smi_sig=1"

but now there is another problem: According to /sys/devices/system/cpu/cpu0/cpufreq/ my laptop supports only 750 and 500 mhz, but I want a lot more freedom for setting cpu speeds...Is there ANY possibility to FORCE other frequencies? I guess not, because its defined by the bios, but would be nice if someone can tell me.

Strange thing is: Klaptop is possible to change the speed of the cpu a lot mir precisely, but not over the real CPU (/proc/cpuinfo has a constand speed) but it definetly changes something over some ACPI states I guess (at least nbench gives different results for the different states).

But I really liked the possibilitys of CPUFreq (setting different profiles for different battery states, or for special programs and things like that, is that also possible only with acpid???)

----------

## vodkin40

 *Sgeorg wrote:*   

> it's quite easy:
> 
> performance governor only means set current speed to currently set maximum
> 
> ...
> ...

 

So it means that even if I compile kernel without governors, cpufreq would still bring frequency down if I unplug?

 *Sgeorg wrote:*   

> 
> 
> as I know (and I really think I now, but prove me wrong)  there is no connection between klaptop and acpid and it's scripts.
> 
> 

 

Ok, but what takes precedence?

----------

## Sgeorg

 *Quote:*   

> So it means that even if I compile kernel without governors, cpufreq would still bring frequency down if I unplug? 

 

You need at least one governor installed, it doesn't work without one, because 

with no governor the "user" (a real one or a process) can't access the setting of at least the "cpu_cur_freq" maybe the min max setting too (don't think so).

and without performance or powersave the scaler doesn't know what to set (min or max).

But you still need a "driver" for interfacing your specific HW (speedstep, powernow......)

especially cpudynd or cpuspeedy...... needs the userspace gov.

cpufreqd, I think only needs performance or powersave gov. but don't nail me to that.

          governor

                |

      e.g.: speedstep

                |

              cpu

 *Quote:*   

> Ok, but what takes precedence?

 

none (or the faster one), you shouldn't / mustn'd use two programms controlling the cpuspeed, because one tows in this the other in that direction and in the end it's only inproductive.

btw, acpid can't controll cpuspeed directly, only threw user written scripts which are triggered by acpi events (buttons, battery..........)

Georg

@Flintz: I come on you back later

----------

## brodo

 *Sgeorg wrote:*   

>  *Quote:*   So it means that even if I compile kernel without governors, cpufreq would still bring frequency down if I unplug?  
> 
> You need at least one governor installed, it doesn't work without one, because 
> 
> with no governor the "user" (a real one or a process) can't access the setting of at least the "cpu_cur_freq" maybe the min max setting too (don't think so).
> ...

 

Quite exactly. You need the cpufreq core, a hardware driver (which may be of speedstep or powernow flavour, or something more... exotic), and a governor running. The governor decides which speed to run at -- it must be somewhere between scaling_min_freq and scaling_max_freq. The powersave and performance governors are quite stupid; they always set it to scaling_min_freq or scaling_max_freq, respectively. The userspace governor is a bit more advanced, it takes input from userspace. This may be the user directly echoing frequencies into the kernel, or a userspace tool like cpudyn, cpuspeedy and so on. The most advanced governor you'll find in 2.6.9 is the "ondemand" governor which dynamically adjusts frequencies based on system load.

 *Sgeorg wrote:*   

> 
> 
>           governor
> 
>                 |
> ...

 

Exactly. And _sometimes_

userspace helper, e.g. cpudyn

           |

userspace governor

           |

e.g. powernow

           |

          cpu

 *Sgeorg wrote:*   

>  *Quote:*   Ok, but what takes precedence? 
> 
> none (or the faster one), you shouldn't / mustn'd use two programms controlling the cpuspeed, because one tows in this the other in that direction and in the end it's only inproductive.

 

Unfortunately, the most broken userspace helpers which misuse the scaling_{min,max}_freq interface take precedence... so you should _either_ use the ondemand govenor, or the userspace governor _and_ _one_ of the userspace helpers.

----------

## brodo

 *vodkin40 wrote:*   

> So it means that even if I compile kernel without governors, cpufreq would still bring frequency down if I unplug?

 

The cpufreq core in the kernel isn't informed of (un)plug events.[*] So you need to handle this event in the userspace tools whcih _are_ informed [e.g. acpid] and modify cpufreq policies (a policy consists of scaling_min_freq / scaling_max_freq / governor) accordingly.

[*] An exception may be in ACPI-related drivers. But using the PPC mechanism for BIOS-enforced prolonging of battery usage time is broken, so let's not discuss this in detail here.

----------

## brodo

 *Flintz wrote:*   

> Ok, I got Speedstep working...at least somehow. I had to compile the Speedstep support as a module and load it with "modprobe speedstep-smi smi_port=0xb2 smi_cmd=0x82 smi_sig=1"

 

You can also build it into the kernel and pass 

```
speedstep-smi.smi_port=0xb2 speedstep-smi.smi_cmd=0x82 speedstep-smi.smi_sig=1
```

 on the boot command line

 *Flintz wrote:*   

> but now there is another problem: According to /sys/devices/system/cpu/cpu0/cpufreq/ my laptop supports only 750 and 500 mhz, but I want a lot more freedom for setting cpu speeds...

 

Your CPU only supports two multipliers, and thus only these two _scaling_ frequencies. Else we'd make them available to you.

 *Flintz wrote:*   

> Is there ANY possibility to FORCE other frequencies? I guess not, because its defined by the bios, but would be nice if someone can tell me.

 

You can modulate the CPU frequency using ACPI throttling. However, this won't save you any energy or prolong the battery usage, so other OSes making "use" of it get it wrong.

 *Flintz wrote:*   

> Strange thing is: Klaptop is possible to change the speed of the cpu a lot mir precisely, but not over the real CPU (/proc/cpuinfo has a constand speed) but it definetly changes something over some ACPI states I guess (at least nbench gives different results for the different states).

  Then the authors of Klaptop didn't read the processor specifications closely enough. THrottling means the CPU needs _more_ energy for any given task to compute...

----------

## vodkin40

All right, thanks guys! All of my qustions has been answered. I think Power Management Guide needs an update and I am going to figure out how to submit a documentation patch

----------

## Sgeorg

one small amendment, throttling makes sence, but only for thermal issues. So if you want passive cooling, throttling is the way of controlling thermal instead of the fan.

Georg

ps: as I'm aware of, the cpu doesn't need more energie whilest throtteled (I mean directly more). because if it's needing more energy there wouldn't be any thermal gain (a cooler cpu). but it needs more energie if you do a cost effort calculation. --> if throtteled the cpu doesn't need significantly less energie (it does use lesses energie, definitly) but it's calculation power is reduced significantly.

----------

## brodo

 *Sgeorg wrote:*   

> one small amendment, throttling makes sence, but only for thermal issues. So if you want passive cooling, throttling is the way of controlling thermal instead of the fan.

  However, CPU frequency scaling is better for this issue, too.

 *Sgeorg wrote:*   

> ps: as I'm aware of, the cpu doesn't need more energie whilest throtteled (I mean directly more). because if it's needing more energy there wouldn't be any thermal gain (a cooler cpu). but it needs more energie if you do a cost effort calculation. --> if throtteled the cpu doesn't need significantly less energie (it does use lesses energie, definitly) but it's calculation power is reduced significantly.

  indeed.

----------

## Flintz

ok, yesterday I did a lot of batterytesting   :Cool: 

Here is what I did:

I set the timeout for monitor to 2,5 mins so that nealry only the cpu drains emergy. Then I loaded nbench in a loop and let it run for 1 hour after that I checked the battery status (battery was always recharged to 100% after each test).

Thats the results of the 4 tests:

1st test: running at full speed (750 Mhz): battery was at 72% after one hour

2nd test: running at speedstep speed (500 Mhz): battery was at 82%

3rd test: running at ACPI throttled speed (a bit less than 500 Mhz, 63% of original speed): battery was at 84%

4rd test: running at the lowest ACPI state possible (only 13% of original speed): battery was at 93%

so I guess even ACPI makes some sense...these tests where all made under 100% load, don't have any idea how it would look like if the cpu would be idle...

BTW I am guessing that my battery isn't discharged linearly...I had the impression that the first 5-6% take very long and then it discharges faster. Thus the estimated running time isn't really accurate as I think it calculates it from the amount of time the last percent took and then calculates it to the remaining percents. But I can't proof it   :Rolling Eyes: 

I need some learning battery monitor (currently I use wmlaptop under fluxbox)...but probably I am wrong...mooooore testing   :Laughing: 

----------

## brodo

 *Flintz wrote:*   

> ok, yesterday I did a lot of batterytesting  8) 
> 
> Here is what I did:
> 
> I set the timeout for monitor to 2,5 mins so that nealry only the cpu drains emergy. Then I loaded nbench in a loop and let it run for 1 hour after that I checked the battery status (battery was always recharged to 100% after each test).
> ...

 

Your testing is broken in one regard: running nbench in a loop. If you do enable throttling, this loop isn't executed as many times as if you don't enable throttling. So of course throttling will reduce the energy usage then. But usually you want tasks to finnish soon; and for any given computing task throttling will cause for more energy to be used: running at 13% of original speed means nbench did only run one eigth of the commands compared to full speed. Assuming the battery discharge is linear, this means the battery will be discharged to 44% if calculating as much data on T7 as is done in one hour on T0 and P0.

----------

## Flintz

when compiling or something like this you are right, but what about web-browsing? or writing some textes etc.? when doing this I want time at any cost, but then web browsing doesn't take 100% cpu load.

But your argumentation has some weak point: after you the whole speedstep technology would be senseless. See in my tests I did 2 tests, one with the cpu throttled to 500 Mhz by speedstep and one throttled to approx. 500 mhz using acpi, same battery drain  :Smile: 

----------

## brodo

 *Flintz wrote:*   

> when compiling or something like this you are right, but what about web-browsing? or writing some textes etc.? when doing this I want time at any cost, but then web browsing doesn't take 100% cpu load.

  That's the point. If the CPU is idle, it's put into a low power mode as well. And that low power mode is technically equivalent to throttling

 *Flintz wrote:*   

> But your argumentation has some weak point: after you the whole speedstep technology would be senseless.

  I wouldn't spend so much time on it if it were senseless. Throttling is much more senseless so I spend much less time on it.  *Flintz wrote:*   

> See in my tests I did 2 tests, one with the cpu throttled to 500 Mhz by speedstep and one throttled to approx. 500 mhz using acpi, same battery drain :)

  That's indeed a strange finding. Doing the maths based on the processor specification gives a much clearer picture. And doing fine-grained measurements (and not using battery rates as mentioned in ACPI) proved the theory, IIRC.

----------

## Earthwings

 *vodkin40 wrote:*   

> All right, thanks guys! All of my qustions has been answered. I think Power Management Guide needs an update and I am going to figure out how to submit a documentation patch

 

What should be updated in your opinion?

----------

## vodkin40

 *Earthwings wrote:*   

>  *vodkin40 wrote:*   All right, thanks guys! All of my qustions has been answered. I think Power Management Guide needs an update and I am going to figure out how to submit a documentation patch 
> 
> What should be updated in your opinion?

 

Briefly:

-relationship between acpi, processor driver and power governors should be described in more detail

-laptop-tools package is not mentioned at all

-should mention power management utilities in various desktop enviroments and how they relate to global X settings and to user's ACPI scripts

-improve sample scripts. For example, add ACPI button event handlers with reasonable default actions

----------

## Earthwings

 *vodkin40 wrote:*   

> 
> 
> -relationship between acpi, processor driver and power governors should be described in more detail
> 
> 

 

I'll have a look at this.

 *vodkin40 wrote:*   

> 
> 
> -laptop-tools package is not mentioned at all
> 
> 

 

You mean laptop-mode-tools? This is blocked by https://bugs.gentoo.org/show_bug.cgi?id=45593

 *vodkin40 wrote:*   

> 
> 
> -should mention power management utilities in various desktop enviroments and how they relate to global X settings and to user's ACPI scripts
> 
> 

 

I'm not too sure how it should look like. Maybe you can elaborate a bit on this.

 *vodkin40 wrote:*   

> 
> 
> -improve sample scripts. For example, add ACPI button event handlers with reasonable default actions
> 
> 

 

I'm already working on it.

Thanks for your suggestions.

----------

## vodkin40

 *Earthwings wrote:*   

> 
> 
>  *vodkin40 wrote:*   
> 
> -laptop-tools package is not mentioned at all
> ...

 

Yes, I meant laptop-mode-tools. Was sure that it is already in portage - what I was smoking?   :Smile:  Anyway, may be it worth adding this link: http://www.xs4all.nl/~bsamwel/laptop_mode/ to the power management guide while things are being fixed

 *Earthwings wrote:*   

> 
> 
>  *vodkin40 wrote:*   
> 
> -should mention power management utilities in various desktop enviroments and how they relate to global X settings and to user's ACPI scripts
> ...

 

I will talk about KDE, but probably this also applies to GNOME:

- Power management guide talks about global settings, detached from desktop manager you use. So as long as you work in the console or in plain X, everything is hunky-dory

- You emerge KDE and discover that you can conveniently set monitor power options from the control center. KDE is absolutely unaware of your global settings in xorg.conf

- KDE also has this little neat program - klaptop. It allows you to set ACPI action events (select power profiles on battery plug/unplug, suspend/hibernate on lid close etc). I didn't look into source code, but earlier in this thread people said that if I create set of global ACPI event scripts and later use klaptop, there will be a conflict because klaptop doesn't have knowledge of global settings.

So from all of this it seems that KDE configuration tools need to be more aware of global settings, but it wouldn't hurt if we add couple of paragraphs to PMG talking about PM utilities in desktop managers and potential conflict.

I promise I will check klaptop source and get back with more facts

 *Earthwings wrote:*   

> 
> 
>  *vodkin40 wrote:*   
> 
> -improve sample scripts. For example, add ACPI button event handlers with reasonable default actions
> ...

 

I saw really cool thread with bunch of ACPI scripts but lost the URL and can not find it right now. Will edit the post when I do

Here is the link:

https://forums.gentoo.org/viewtopic.php?t=80077&highlight=laptopmode

----------

## Mnemia

Hi,

This might be a little bit offtopic, but you guys seemed pretty informed about the various options. I've recently upgraded to the new 2.6.9 kernel on my laptop and I've been trying to get the "ondemand" scaling governor to work. The problem is that it doesn't change to it when I send it the command to do so.

```

luna root # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors 

ondemand powersave performance 

luna root # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 

powersave

luna root # echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 

luna root # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 

powersave

```

As you can see, the change simply doesn't "take" when it's the ondemand driver. It works fine when I change between any of the others, but not with ondemand.

Google wasn't immediately productive on this, but maybe I'm not digging deep enough.

----------

## Earthwings

The same problem was reported in the German forums. You don't have any other tool like cpudyn, speedfreqd running, do you? Does dmesg complain about anything when you try to change? Have you tried to enable ACPI debugging?

@vodkin40: /me is working on an updated guide, draft is available. It's not complete yet.

----------

## Mnemia

 *Earthwings wrote:*   

> The same problem was reported in the German forums. You don't have any other tool like cpudyn, speedfreqd running, do you? Does dmesg complain about anything when you try to change? Have you tried to enable ACPI debugging?
> 
> 

 

I'm not running any userspace tools, no. Until now I had the powersave governor on in order to keep my system cooler (run at low speed). I haven't tried looking into ACPI debugging for this specific issue yet although I've used it in the past when dealing with a different problem. dmesg prints absolutely nothing when I issue any of those commands.

Actually, just now I've noticed that my issuing that command may actually have done something. My CPU frequency appears to have increased to the maximum, which I don't think it will do with the powersave governor. Maybe the ondemand governor is actually working but simply not being reported through the /sys interface...

----------

## brodo

which cpufreq driver are you using, Mnemia?

----------

## Mnemia

```

jeff@luna jeff $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver   

speedstep-ich

```

----------

## brodo

 *Mnemia wrote:*   

> 
> 
> ```
> 
> jeff@luna jeff $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver   
> ...

 

NB: sorry for this post being in German at first.

The speedstep-ich driver doesn't know exactly how long the CPU needs to switch between the two frequencies, or how long to wait between such switches. Therefore, "latency" is set to "CPUFREQ_ETERNAL" to be on the safe side...

However, you can try out the following:

a) use the cpufreq driver called "acpi" or "cpufreq-acpi" (or is it "acpi-cpufreq"? I forgot...) - it has proper knowledge of latencies; and you can determine them by looking at /proc/acpi/processor/*/performance [if you enabled the proc interface, sysfs interface is in the working]

b)  on your own risk: set the value for latency to something really large (the value is in nanoseconds, 1 second = 1000000000 [10^9] nanoseconds!), check the stability of this running with ondemand, and then lower "latency" carefully, re-test, and lower again. I'd not try lowering it below 500 us = 500000 ns, though! BE CAREFULLast edited by brodo on Sun Oct 31, 2004 9:22 pm; edited 2 times in total

----------

## Earthwings

A translation would make some people happy, I guess  :Smile: 

----------

## brodo

... sorry about that.  :Embarassed: 

----------

## Shadow Skill

I have an amd3200+ and I was llooking at the ondemand govenor in my kernel config and I was wonder just what it did for x86_84 systems, could someone please explain to me in simple terms what this govenor does and if there is a benefit to using it on an x86_64 machine?  Is there any configuration that must be done for it to work or is turning it on and recompiling the kernel all that is needed?

----------

## brodo

 *Shadow Skill wrote:*   

> I have an amd3200+ and I was llooking at the ondemand govenor in my kernel config and I was wonder just what it did for x86_84 systems, could someone please explain to me in simple terms what this govenor does and if there is a benefit to using it on an x86_64 machine?

  It reduces the CPU frequency and the voltage the CPU runs at if there is no or few work for the CPU to do.

 *Shadow Skill wrote:*   

> Is there any configuration that must be done for it to work or is turning it on and recompiling the kernel all that is needed?

  You also need to either emerge a cpufreq userspace daemon _or_ cpufrequtils-0.3-r1 and add cpufreq to a runlevel of your choice.

----------

## Shadow Skill

Thanks Brodo guess its time to recompile the kernel.  Just so you know rc-update wanted cpufrequtils as oppossed to just cpufreq.

----------

