Since i test kernel 3.9-rc2, cpufreq is crazy with governors ondemand and conservative. Even if the system is idling, cpufreq is on the highest or medium frequency. Only with powersafe i can get the cpu to the lowest frequency. This behavior i cant see in 3.8 or below. Here the output from cpufreq-info: cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 10.0 us. hardware limits: 1.60 GHz - 2.66 GHz available frequency steps: 2.66 GHz, 2.13 GHz, 1.60 GHz available cpufreq governors: powersave, conservative, userspace, ondemand, performance current policy: frequency should be within 1.60 GHz and 2.66 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 1.60 GHz. cpufreq stats: 2.66 GHz:3.10%, 2.13 GHz:3.09%, 1.60 GHz:93.81% (8123) analyzing CPU 1: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 10.0 us. hardware limits: 1.60 GHz - 2.66 GHz available frequency steps: 2.66 GHz, 2.13 GHz, 1.60 GHz available cpufreq governors: powersave, conservative, userspace, ondemand, performance current policy: frequency should be within 1.60 GHz and 2.66 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 1.60 GHz. cpufreq stats: 2.66 GHz:3.10%, 2.13 GHz:3.09%, 1.60 GHz:93.81% (8123) analyzing CPU 2: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 10.0 us. hardware limits: 1.60 GHz - 2.66 GHz available frequency steps: 2.66 GHz, 2.13 GHz, 1.60 GHz available cpufreq governors: powersave, conservative, userspace, ondemand, performance current policy: frequency should be within 1.60 GHz and 2.66 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 1.60 GHz. cpufreq stats: 2.66 GHz:3.10%, 2.13 GHz:3.09%, 1.60 GHz:93.81% (8123) analyzing CPU 3: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 10.0 us. hardware limits: 1.60 GHz - 2.66 GHz available frequency steps: 2.66 GHz, 2.13 GHz, 1.60 GHz available cpufreq governors: powersave, conservative, userspace, ondemand, performance current policy: frequency should be within 1.60 GHz and 2.66 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 1.60 GHz. cpufreq stats: 2.66 GHz:3.10%, 2.13 GHz:3.09%, 1.60 GHz:93.81% (8123)
Hi, I was the guy behind most of the cpufreq core updates in this kernel release. I haven't tried to reproduce the problem you got (was very busy with some other activity), but i am trying to analyse what may cause it. Following are the important updates that i can make out from: 'git diff v3.8..v3.9-rc2' - Locking Fixes - policy->cpus and policy->related_cpus fixups - simplification of cpu hotplug path in cpufreq core - removing redundant code between governors I don't really think any of the above can cause this problem, unless there is a bug somewhere. - per cpu timer for both ondemand and conservative: commit 2abfa876f1117b0ab45f191fb1f82c41b1cbc8fe Author: Rickard Andersson <rickard.andersson@stericsson.com> Date: Thu Dec 27 14:55:38 2012 +0000 cpufreq: handle SW coordinated CPUs This patch fixes a bug that occurred when we had load on a secondary CPU and the primary CPU was sleeping. Only one sampling timer was spawned and it was spawned as a deferred timer on the primary CPU, so when a secondary CPU had a change in load this was not detected by the cpufreq governor (both ondemand and conservative). This patch make sure that deferred timers are run on all CPUs in the case of software controlled CPUs that run on the same frequency. This can be behind all the problem you are facing. Can you try reverting all patches including and after this patch? If any of the cpu is loaded enough, then you will see some freq used (based on the load). Whereas, earlier if cpu0 goes down, then we were just not re-evaluating load at all. -- viresh
Hi towo, Can you please follow Viresh's suggestion in comment #1 to test out? Thanks.
Sorry for the long delay, but it seems all is good. If i check the frewuency with watch -n 0,5 cpufreq-info all is good, only conky is showing those fancy freqency changes. So i would resume, it's conky's fault.