I have a Lenovo T520 with a Intel(R) Core(TM) i5-2450M CPU and a Sandy Bridge chipset. Starting from kernel version 3.9.1 I switched the CPU frequency scaling driver from acpi-cpufreq to intel_pstate. In combination with the powersave governor it worked like a charm. I had higher frequencies due to the turbo boost (3.1 GHz instead of 2.5 GHz) and when the system was idle the frequency was switched to the lowest values (around 800 MHz). With the kernel versions 3.9.3 and now even 3.9.4 the frequency remains at a quite high frequency (3.0 or 2.9 GHz) even if the the system is completely idle. As I have not changed the kernel-config when I updated to the versions 3.9.3 and 3.9.4 I assume some bug was introduced in the kernel as of 3.9.3. Please let me know if you need any further info. Christoph
On Saturday, May 25, 2013 07:24:54 AM bugzilla-daemon@bugzilla.kernel.org wrote: [...] > > With the kernel versions 3.9.3 and now even 3.9.4 the frequency remains at a > quite high frequency (3.0 or 2.9 GHz) even if the the system is completely > idle. > > As I have not changed the kernel-config when I updated to the versions 3.9.3 > and 3.9.4 I assume some bug was introduced in the kernel as of 3.9.3. > > Please let me know if you need any further info. Can you possibly identify the change between 3.9.1 and 3.9.3 that introduced the problem for you?
At first I have to add that also kernel 3.9.2 worked. According to the changelog of kernel 3.9.3 between 3.9.2 and 3.9.3 three commitments concerning intel_pstate (b540137a810d0267051c538e68d4348e43a1edf3, 2aa491f8bdcac932006548b1a2b655b29c942e08 and 1abc4b20b85b42e8573957e54b193385cf48b0d6) have been added to the kernel. I guess that one of them might be the culprit. As I am rather a user it's only possible for me to describe the symptoms. With kernel 3.9.2, when the system is idle according to cpufreg-info the frequency of all cpu's is between 775 and 800 MHz, which is the minimum. With kernel 3.9.3 and 3.9.4 it never goes below 2.85 GHz. In both cases intel_pstate is the driver and powersave the governor. Christoph
In the meantime I have made a git bisect between kernel 3.9.2 and 3.9.3 with the following result: 5aacc8bcf0b23e20cbb205ac6fdc3ce797e1cae2 is the first bad commit commit 5aacc8bcf0b23e20cbb205ac6fdc3ce797e1cae2 Author: Dirk Brandewie <dirk.j.brandewie@intel.com> Date: Tue May 7 08:20:25 2013 -0700 cpufreq / intel_pstate: remove idle time and duration from sample and calculations commit 1abc4b20b85b42e8573957e54b193385cf48b0d6 upstream. In order to confirm this is the relevant commit I have compiled a 3.9.3 kernel where I had reverted the changes provided by this commit. With this kernel booted the frequency switching works again. I hope that helps. Christoph
Can you attach your kernel config file please.
Created attachment 102571 [details] Kernel config 3.9.3 Here is my kernel-config. Christoph
Hi Christoph, I haven't bee able to reproduce yet. Could you build tools/power/cpupower in your kernel tree and post the results of: cpupower -c 0-4 frequency-info I am not expecting anything earth shattering here I just want to make sure we are doing an apples to apples comparison.
Created attachment 102731 [details] cpupower.output Here is the output of 'cpupower -c 0-3 frequency-info', made, when the system was completely idle. If I use a kernel that does not contain the respective commit the frequency of all cpu's is at 775 or 800 MHz. Christoph
For me it happens only after resuming from suspend to RAM. The frequency stays at max (2.3 GHz for me, Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz). This results to a temperature bigger than 10 degrees Celsius in relation to kernel versions without pstate and a significant lower battery life. Disabling pstate (intel_pstate=disable) doesn't solve the issue. I build the kernel with CONFIG_X86_INTEL_PSTATE=N and the problem remains. I use ArchLinux. Have a look at the following threads. https://bbs.archlinux.org/viewtopic.php?pid=1279373#p1279373 https://bbs.archlinux.org/viewtopic.php?id=163854 The problem started with linux-3.9.2. It was ok until 3.8.7. Should I fill another bug report?
Christoph could you attach the output of "ps aux". I am still looking for a way to reproduce this.
Created attachment 102891 [details] ps aux output Here is the output of ps aux. Please let me know if you need any further infos. Christoph
IMHO intel pstate don't care about governors at all. Turboboost had always worked, just userspace utilities could not see it (there are many threads on forums about this). I have Ideapad Z570 and I can confirm that indeed sometimes after CPU heavy tasks, fan just spins at max speed untill I restart laptop (despite 0%-5% cpu usage in top). By the way, this could also be related to ideapad-laptop platform driver, which enables 4 different fan modes, is that thing loaded in on your T520??
#11: On kernels 3.9.[2-4] (only ones I tested)
I also observe this issue after a suspend/resume on 3.9.4. This is on a Thinkpad x220 with Sandy Bridge. All CPUs get pegged at turbo speed yet system is not busy. Suspending/resuming seems to fix it. I've also had it happen once when I unplugged the AC adapter. When it occurs, I see these kernel messages: Jun 03 22:04:34 disaster kernel: CPU2: Package power limit notification (total events = 630) Jun 03 22:04:34 disaster kernel: CPU0: Package power limit notification (total events = 630) Jun 03 22:04:34 disaster kernel: CPU1: Package power limit notification (total events = 630) Jun 03 22:04:34 disaster kernel: CPU3: Package power limit notification (total events = 630)
(In reply to comment #10) > Created an attachment (id=102891) [details] > ps aux output > > Here is the output of ps aux. > > Please let me know if you need any further infos. > > Christoph Can you run turbostat for a few samples and attach the output please TIA --Dirk
Created attachment 103451 [details] turbostat.output
Created attachment 103461 [details] turbostat2.output Here for comparison the output of turbostat with kernel 3.9.4, which I have "patched" by reversely applying the respective commit. Christoph
Christoph: So with the current kernel you are spending a lot more time in a high C-state and using less energy both of which are desirable. Granted you are running at a higher frequency when in C0 but spending about a quarter of the time in C0 than before. The P-state/frequency is selected based on the load while the core is in C0. The current intel_pstate is behaving better than before from a power efficiency point of view which is its job. if you want to see what is causing the load you can use 'perf timechart record' the chromium guts have a nice page on how to use timechart. One warning timechart can create LARGE svg files so you want to keep your sample time fairly short. http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/a-brief-perf-how-to
Dirk, Thank you very much for your efforts. It sounds logical that if the CPUs run at a higher frequency the CPU's load is lower as it would be when the same tasks would be performed at a lower frequency. But do I understand it correctly that even if the frequency is higher, the lower load means in total less power consumption? Christoph
I have made some tests and all I can say is intel_pstate/powersave is worse than ondemand. No network, minimum brightness, running KDE and Skype (offline): ondemand: 6.66W, intel_pstate/powersave: 6.86W No network, minimum brightness, running KDE, Skype and Amarok with music playing: ondemand: 9.71W, intel_pstate/powersave: 9.79W
You're measuring power (average, I suppose?), not energy, but energy is what matters. Power is like a price tag on each time unit spent on computations, but the total amount depends on how much time it takes to complete the workload.
Yes, I'm measuring average power with powertop. When I'm on battery and e.g. listening to music, intel_pstate gives me less working time on battery than ondemand, so just for me I don't think I will use intel_pstate on battery and even on charger, because with intel_pstate laptop fan is almost constantly running, and CPU temperature is higher than on ondemand.
On Tuesday, June 25, 2013 09:35:15 AM you wrote: > --- Comment #21 from ValdikSS <iam@valdikss.org.ru> 2013-06-25 09:35:15 --- > Yes, I'm measuring average power with powertop. > When I'm on battery and e.g. listening to music, intel_pstate gives me less > working time on battery than ondemand, so just for me I don't think I will > use > intel_pstate on battery and even on charger, because with intel_pstate laptop > fan is almost constantly running, and CPU temperature is higher than on > ondemand. That's a convincing argument. Dirk, your opinion?
After some more testing I have to agree with Comment #21 from Rafael. I have made the same observations as he made. Due to the fact that the CPUs run at a higher frequency they produce more heat, which on my laptop makes the fan constantly running. In total the additional power consumption caused by the fan exceeds by far the saving effects resulting from the CPUs spending more time in a high C-state. For me that has the effect, that with acpi-cpufreq and ondemand under normal workload the average time until the fully loaded battery of my laptop is empty is approx. two hours but it is reduced to approx. only one hour with intel-pstate and powersave. Before the commit I mentioned in comment #3 was added to the kernel, the power consumption using intel-pstate and powersave was however less than with acpi-cpufreq and ondemand. With all due respect I would recommend to reconsider the approach to have the CPUs running at a higher C-state/frequency. At least for laptop users like me this means a big advantage. Christoph
Some more details to my comment #23 above: Using intel_pstate with the actual kernel 3.10.5 the CPUs constantly run at a frequency 2.9 GHz even if the system is idle. This keeps the CPU temperature at 65 C and above and the fan is constantly running at high speed. For testing I have removed in the kernel sources all changes to /drivers/cpufrequ/intel_pstate.c that were introduced since kernel 2.9.2. The CPUs now run mostly at 800MHz and the CPU temperature is below 50 C which means that the fan is either running at low speed or off.With respect to battery time this makes a difference of about one hour. Christoph
So guys, I suppose this is fixed with the following commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=40e2d7f9b5dae048789c64672bf3027fbb663ffa
And it's apparently not.
*** This bug has been marked as a duplicate of bug 66581 ***
Christoph, Please re-open if your system is not fixed by the update mentione din bug 66581 ValdlkSS, No, that commit is not related to this issue.