[BISECTED] "conservative" cpufreq governor broken
From: Steven Noonan
Date: Mon Oct 05 2009 - 12:33:27 EST
I noticed on my machine that the "conservative" cpufreq governor wasn't
working properly in v2.6.31.1 or Linus' latest tree, but it worked fine on
v2.6.30.8, so I decided I should figure out where this issue was coming
from. The issue is pretty clear...
Here's the expected:
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@xxxxxxxxxxxxxxx, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.33 GHz
available frequency steps: 2.33 GHz, 2.17 GHz, 2.00 GHz, 1.83 GHz, 1.67 GHz, 1.50 GHz, 1.33 GHz, 1000 MHz
available cpufreq governors: ondemand, userspace, powersave, conservative, performance
current policy: frequency should be within 1000 MHz and 2.33 GHz.
The governor "conservative" may decide which speed to use
within this range.
current CPU frequency is 1000 MHz (asserted by call to hardware).
cpufreq stats: 2.33 GHz:0.59%, 2.17 GHz:1.41%, 2.00 GHz:0.88%, 1.83 GHz:1.22%, 1.67 GHz:0.88%, 1.50 GHz:1.41%, 1.33 GHz:10.98%, 1000 MHz:82.63% (33)
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 1
hardware limits: 1000 MHz - 2.33 GHz
available frequency steps: 2.33 GHz, 2.17 GHz, 2.00 GHz, 1.83 GHz, 1.67 GHz, 1.50 GHz, 1.33 GHz, 1000 MHz
available cpufreq governors: ondemand, userspace, powersave, conservative, performance
current policy: frequency should be within 1000 MHz and 2.33 GHz.
The governor "conservative" may decide which speed to use
within this range.
current CPU frequency is 1000 MHz (asserted by call to hardware).
cpufreq stats: 2.33 GHz:0.40%, 2.17 GHz:0.16%, 2.00 GHz:0.16%, 1.83 GHz:0.35%, 1.67 GHz:0.16%, 1.50 GHz:0.35%, 1.33 GHz:0.16%, 1000 MHz:98.27% (7)
And here is the broken version (note the 'cpufreq stats' line):
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@xxxxxxxxxxxxxxx, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.33 GHz
available frequency steps: 2.33 GHz, 2.17 GHz, 2.00 GHz, 1.83 GHz, 1.67 GHz, 1.50 GHz, 1.33 GHz, 1000 MHz
available cpufreq governors: ondemand, userspace, powersave, conservative, performance
current policy: frequency should be within 1000 MHz and 2.33 GHz.
The governor "conservative" may decide which speed to use
within this range.
current CPU frequency is 2.33 GHz (asserted by call to hardware).
cpufreq stats: 2.33 GHz:100.00%, 2.17 GHz:0.00%, 2.00 GHz:0.00%, 1.83 GHz:0.00%, 1.67 GHz:0.00%, 1.50 GHz:0.00%, 1.33 GHz:0.00%, 1000 MHz:0.00%
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 1
hardware limits: 1000 MHz - 2.33 GHz
available frequency steps: 2.33 GHz, 2.17 GHz, 2.00 GHz, 1.83 GHz, 1.67 GHz, 1.50 GHz, 1.33 GHz, 1000 MHz
available cpufreq governors: ondemand, userspace, powersave, conservative, performance
current policy: frequency should be within 1000 MHz and 2.33 GHz.
The governor "conservative" may decide which speed to use
within this range.
current CPU frequency is 2.33 GHz (asserted by call to hardware).
cpufreq stats: 2.33 GHz:100.00%, 2.17 GHz:0.00%, 2.00 GHz:0.00%, 1.83 GHz:0.00%, 1.67 GHz:0.00%, 1.50 GHz:0.00%, 1.33 GHz:0.00%, 1000 MHz:0.00%
So basically, it just never clocks down from the maximum frequency.
Here's the bisection log:
# bad: [2147b209] Linux 2.6.31.1
# good: [a1c4c06a] Linux 2.6.30.8
# good: [07a2039b] Linux 2.6.30
# good: [452dac45] V4L/DVB (11761): dvb-ttpci: Fixed VIDEO_SLOWMOTION
# bad: [906e8d97] e1000e: delay second read of PHY_STATUS register o
# good: [36e84467] Staging: heci: fix userspace pointer mess
# bad: [df36b439] Merge branch 'for-2.6.31' of git://git.linux-nfs.o
# skip: [12e24f34] Merge branch 'perfcounters-fixes-for-linus' of git
# good: [48c93112] powerpc: Fix invalid construct in our CPU selectio
# bad: [eca41044] n_r3964: fix lock imbalance
# good: [93db6294] Merge branch 'for-linus' of git://git.kernel.org/p
# bad: [1eb51c33] Merge branch 'sched-fixes-for-linus' of git://git.
# good: [1d991001] Merge branch 'x86/mce3' into x86/urgent
# good: [71e308a2] function-graph: add stack frame test
# bad: [38df92b8] Merge branch 'timers-fixes-for-linus' of git://git
# good: [ad5cf46b] Merge git://git.kernel.org/pub/scm/linux/kernel/gi
# good: [7fd5b632] Merge branch 'for-linus' of git://git.monstr.eu/li
# good: [c4c5ab30] Merge branch 'x86-fixes-for-linus' of git://git.ke
# bad: [f2e21c96] NOHZ: Properly feed cpufreq ondemand governor
And finally, the commit that broke "conservative":
commit f2e21c9610991e95621a81407cdbab881226419b
Author: Eero Nurkkala <ext-eero.nurkkala@xxxxxxxxx>
Date: Mon May 25 09:57:37 2009 +0300
NOHZ: Properly feed cpufreq ondemand governor
A call from irq_exit() may occasionally pause the timing
info for cpufreq ondemand governor. This results in the
cpufreq ondemand governor to fail to calculate the
system load properly. Thus, relocate the checks for this
particular case to keep the governor always functional.
Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@xxxxxxxxx>
Reported-by: Tero Kristo <tero.kristo@xxxxxxxxx>
Acked-by: Rik van Riel <riel@xxxxxxxxxx>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@xxxxxxxxx>
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
I'd work on fixing it myself and whip up a patch, but I'm going to be gone
all day and I'm not too familiar with cpufreq anyway.
- Steven
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/