Bug 58801

Summary: intel_pstate/powersave - cpu frequency remains at high level if if system is idle
Product: Power Management Reporter: Christoph Loehr (c.h.l)
Component: cpufreqAssignee: Dirk Brandewie (dirk.brandewie)
Status: CLOSED DUPLICATE    
Severity: normal CC: alexkaltsas, bugs+kernel, dirk.brandewie, iam, james.ravn, kernel.org, lenb, pruzinat, rjw
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.9.3 and 3.9.4 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Kernel config 3.9.3
cpupower.output
ps aux output
turbostat.output
turbostat2.output

Description Christoph Loehr 2013-05-25 07:24:54 UTC
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
Comment 1 Rafael J. Wysocki 2013-05-25 09:07:20 UTC
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?
Comment 2 Christoph Loehr 2013-05-25 09:39:02 UTC
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
Comment 3 Christoph Loehr 2013-05-25 14:57:21 UTC
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
Comment 4 Dirk Brandewie 2013-05-25 16:30:58 UTC
Can you attach your kernel config file please.
Comment 5 Christoph Loehr 2013-05-25 17:34:51 UTC
Created attachment 102571 [details]
Kernel config 3.9.3

Here is my kernel-config.

Christoph
Comment 6 Dirk Brandewie 2013-05-28 16:43:52 UTC
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.
Comment 7 Christoph Loehr 2013-05-28 19:56:08 UTC
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
Comment 8 Alexander Kaltsas 2013-05-28 21:44:16 UTC
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?
Comment 9 Dirk Brandewie 2013-05-29 18:01:39 UTC
Christoph could you attach the output of "ps aux".  I am still looking for a way to reproduce this.
Comment 10 Christoph Loehr 2013-05-29 21:38:02 UTC
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
Comment 11 Tomáš Pružina 2013-06-02 15:37:50 UTC
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??
Comment 12 Tomáš Pružina 2013-06-02 15:38:51 UTC
#11: On kernels 3.9.[2-4] (only ones I tested)
Comment 13 James Ravn 2013-06-04 16:18:03 UTC
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)
Comment 14 Dirk Brandewie 2013-06-04 16:27:33 UTC
(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
Comment 15 Christoph Loehr 2013-06-04 21:33:47 UTC
Created attachment 103451 [details]
turbostat.output
Comment 16 Christoph Loehr 2013-06-04 21:42:43 UTC
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
Comment 17 Dirk Brandewie 2013-06-04 22:23:07 UTC
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
Comment 18 Christoph Loehr 2013-06-08 06:28:15 UTC
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
Comment 19 ValdikSS 2013-06-24 11:41:05 UTC
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
Comment 20 Rafael J. Wysocki 2013-06-24 23:25:21 UTC
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.
Comment 21 ValdikSS 2013-06-25 09:35:15 UTC
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.
Comment 22 Rafael J. Wysocki 2013-06-25 22:27:56 UTC
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?
Comment 23 Christoph Loehr 2013-08-07 17:59:20 UTC
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
Comment 24 Christoph Loehr 2013-08-07 21:44:46 UTC
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
Comment 25 ValdikSS 2014-01-01 14:40:01 UTC
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
Comment 26 ValdikSS 2014-01-12 17:11:30 UTC
And it's apparently not.
Comment 27 Dirk Brandewie 2014-02-03 16:41:26 UTC

*** This bug has been marked as a duplicate of bug 66581 ***
Comment 28 Len Brown 2014-06-16 17:50:53 UTC
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.