BenV's notes

You know what’s really annoying?

Try this:

root@Uil:/sys/devices/system/cpu/cpu0/cpufreq:0>echo ondemand > scaling_governor
root@Uil:/sys/devices/system/cpu/cpu0/cpufreq:0>dmesg
[1325843.712549] ondemand governor failed, too long transition latency of HW, fallback to performance governor


Apparently this is caused by the p4-clockmod module.
You know, this piece of junk:

Also known as “CONFIG_X86_P4_CLOCKMOD“.

The reason?
Well, the ondemand and the conservative governors want to be able to switch to a different speed before their calculations become invalid.
The p4-clockmod thing apparently makes the latency of switching so BIG that it becomes impossible. Or so they think.
Which leaves only the sucky powersave and performance governors. (and of course userspace).

The kernel menuconfig help states:

This driver should be only used in exceptional
circumstances when very low power is needed because it causes severe
slowdowns and noticeable latencies. Normally Speedstep should be used
instead.

Lovely. I’ll keep that in mind, thanks.
*enables CONFIG_X86_ACPI_CPUFREQ instead*

Note that when they’re both compiled in (as opposed to modules) the retarded thing seems to go for the clockmod. Just great.

Or more specific: CPU frequency scaling.

On my laptop this is one of the first things I enabled to make my battery last longer.
Now that we’re going to put a server in a rack where they will bill us depending on the amount of power consumed, this sounds like a welcome thing to have enabled.

Our latest Xen install has Xen 3.4, on which they’ve enabled it by default. Isn’t that nice?
So basically, if your processor etc is good enough to support it, you can mess around with it using the xenpm tool.

For instance we can check the parameters for CPU 0 like this:

root@xenbro:~# xenpm get-cpufreq-para 0
cpu id : 0
affected_cpus : *0 1 2 3
cpuinfo frequency : max [2600000] min [800000] cur [800000]
scaling_driver :
scaling_avail_gov : userspace performance powersave ondemand
current_governor : ondemand
ondemand specific :
sampling_rate : max [10000000] min [10000] cur [20000]
up_threshold : 80
scaling_avail_freq : 2600000 1900000 1400000 *800000
scaling frequency : max [2600000] min [800000] cur [800000]

As you can see, it’s very much like the whole cpufreq ordeal. It has an ondemand governor, a powersave one, etc. Right now this CPU is using the ondemand governor, which will ramp up the clock when demand increases.
However, since this is a quad core and not a real quad processor machine we can only change the governor for all 4 cores at the same time, not for individual ones. (would be cool to have 1 core burning away power while the rest idles by….).

Anyway, the xenpm tool allows us to monitor and change various aspects of this.
For instance this will do a little benchmark and show the processor states during the benchmark.

root@xenbro:~# xenpm start 10
Timeout set to 10 seconds
Start sampling, waiting for CTRL-C or SIGINT or SIGALARM signal ...
Elapsed time (ms): 10003

CPU0: Residency(ms) Avg Res(ms)
C0 49 ( 0.50%) 0.04
C1 9953 (99.50%) 7.19

Avg freq 800000 KHz

CPU1: Residency(ms) Avg Res(ms)
C0 13 ( 0.14%) 0.07
C1 9989 (99.86%) 48.49

Avg freq 800000 KHz

CPU2: Residency(ms) Avg Res(ms)
C0 83 ( 0.83%) 0.21
C1 9919 (99.17%) 25.05

Avg freq 800000 KHz

CPU3: Residency(ms) Avg Res(ms)
C0 28 ( 0.28%) 0.10
C1 9973 (99.72%) 33.92

Avg freq 800000 KHz

As you can see my processor is mostly idle.
State C0 is the most active state, C1 is sleeping with use of the HLT instruction.
Your processor can have many more states, like my laptop which has 4.

Anyway, I put the change to ondemand governor in my /etc/rc.d/rc.local, so let’s hope it helps.

To read some more about the details of this stuff you can check out the Xenpm wiki page.