[Bug 77771] New: Intel P-State: Constantly changing CPU frequencies on idle system.

[Bug 77771] New: Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

            Bug ID: 77771
           Summary: Intel P-State: Constantly changing CPU frequencies on
                    idle system.
           Product: Power Management
           Version: 2.5
    Kernel Version: 3.14.7, 3.15-rc8 - 3.15
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: cpufreq
          Assignee: cpufreq@vger.kernel.org
          Reporter: harn-solo@gmx.de
        Regression: No

With the introduction of the kernel patch 3.14.7 and around the release of
3.15-rc8 the idle CPU frequency of each core in an idle system is changing
erratically.

Before the patch the output of grep MHz /proc/cpuinfo looked like this:

cpu MHz         : 813.625
cpu MHz         : 813.625
cpu MHz         : 813.625
cpu MHz         : 813.625

After the patch:

cpu MHz         : 1600.207
cpu MHz         : 1600.207
cpu MHz         : 1599.847
cpu MHz         : 2342.675

The CPU clocks are wildly changing over the complete spectrum of available
frequencies. I can reproduce the phenomenon on at least three systems:

Desktop PC with Sandy-Bridge CPU: Intel i7-2600 (non-K)
Lenovo T530 with Ivy-Bridge CPU: i7-3610QM
Sony VAIO Pro 13 (example above) with Haswell CPU: i5-4200U

For me it is not clear whether this is expected behavior and I just hit some
kind of heisenbug or something is going wrong. Primarily I report this because
I noticed a significant sudden change. I haven't done any tests regarding
performance, battery run-time or heat implications yet.

Note: I've seen this kind of behavior in earlier kernel releases before, but
with 3.14 it vanished completely. So this might be a regression.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

Doug Smythies <dsmythies@telus.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmythies@telus.net

--- Comment #1 from Doug Smythies <dsmythies@telus.net> ---
Please define "an idle system". I ask because an "idle" linux server computer
can be quite different than and "idle" linux computer with some sort of gui
desktop, the latter being, in reality, actually considerably less "idle".

That being said, your frequencies do seem a little high now. Your previous
frequencies were unduly being forced low and there was a change with respect to
that issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

Yuyang Du <yuyang.du@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yuyang.du@intel.com

--- Comment #2 from Yuyang Du <yuyang.du@intel.com> ---
(In reply to Michael Long from comment #0)
> With the introduction of the kernel patch 3.14.7 and around the release of
> 3.15-rc8 the idle CPU frequency of each core in an idle system is changing
> erratically.
> 

This behavior is expected, see:

http://marc.info/?l=linux-pm&m=140141648726863&w=2

Nothing to say more.

Thanks,
Yuyang

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #3 from Michael Long <harn-solo@gmx.de> ---
To comment #1:

I made my tests on desktop systems with a loaded KDE instance. Aside from "the
usual" services running like in a typical Fedora 20 default installation. There
are no other process active producing considerable load over a longer time.

I just started up, logged into KDE and let is stay for a while (at least 5
mins) and then looked at the frequencies. No browser started, no games loaded,
no update-processes running etc, just an empty desktop.

There is nothing up and running on those systems that justifies having one or
more cores up even deep in some turbo mode when getting the frequency stats.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #4 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 139771
  --> https://bugzilla.kernel.org/attachment.cgi?id=139771&action=edit
turbostat look at idle system

Perhaps provide the output from "turbostat sleep 60" or "turbostat -J sleep
60".
I have attached the result from my system, where my CPU's are all at low
frequency (lowest pstate). My system is a server with no GUI stuff.

I did it as an attachment rather than in-line, so as to (hopefully) not mess up
the formatting.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #5 from Michael Long <harn-solo@gmx.de> ---
Thanks for the hint about the turbostat utility. Without starting a desktop
environment I got similar stats, all frequencies are very close around the
lowest state. Logged into KDE showed different results. Eventually I found the
cause of those high clocks: 

A superkaramba desktop-widget. This widget basically does a grep on
/proc/cpuinfo and checks the load internally each second. Disabling this widget
gets the clock down. The same behavior can be reproduced just by running "for i
in {1..99}; do grep MHz /proc/cpuinfo; sleep 1; done".

Admittedley this might be a typical layer8-problem, however why is a simple
grep every second pounding the CPU so hard that it remains in higher clocks,
even in turbo mode? Especially when it didn't before the patch or just using
plain old acpi-cpufreq. If this is still just expected behavior sorry for the
unnecessary noise.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #6 from Michael Long <harn-solo@gmx.de> ---
Created attachment 140001
  --> https://bugzilla.kernel.org/attachment.cgi?id=140001&action=edit
turbostat results while running simple grep

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #7 from Yuyang Du <yuyang.du@intel.com> ---
(In reply to Michael Long from comment #5)
> Thanks for the hint about the turbostat utility. Without starting a desktop
> environment I got similar stats, all frequencies are very close around the
> lowest state. Logged into KDE showed different results. Eventually I found
> the cause of those high clocks: 
> 
> A superkaramba desktop-widget. This widget basically does a grep on
> /proc/cpuinfo and checks the load internally each second. Disabling this
> widget gets the clock down. The same behavior can be reproduced just by
> running "for i in {1..99}; do grep MHz /proc/cpuinfo; sleep 1; done".
> 
> Admittedley this might be a typical layer8-problem, however why is a simple
> grep every second pounding the CPU so hard that it remains in higher clocks,
> even in turbo mode? Especially when it didn't before the patch or just using
> plain old acpi-cpufreq. If this is still just expected behavior sorry for
> the unnecessary noise.

Expected, but should not happen. So clearly something is wrong...

Yuyang

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #8 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 140031
  --> https://bugzilla.kernel.org/attachment.cgi?id=140031&action=edit
two turbostats runs with grep running

Is your turbostat listing for your Haswell computer? I.E. the one where the
minimum CPU frequency is about 800 MHz?

I am unable to repeat your "for i in {1..99}; do grep MHz /proc/cpuinfo; sleep
1; done" results on my computer. I wish that I could. Attached are two
turbostat runs done while that command was running (the 2nd one is probably of
no use to anyone else). My minimum CPU frequency is about 1600 MHz.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #9 from Michael Long <harn-solo@gmx.de> ---
Created attachment 140441
  --> https://bugzilla.kernel.org/attachment.cgi?id=140441&action=edit
Kernel config 3.15

Sorry for the delay, yes the turbostat results are all from the same Haswell
i5-4200U with 800-1600 MHz (turbo 2.9 GHz) [1].

I've no clue why this ultrabook is so sensitive. Hence I've attached my current
kernel-config maybe I've misconfigured something.

In the meantime I tried to find a better method to reproduce the effect but I
had no real luck when testing on my other quad-core systems. There, the effect
is very less severe.



[1]
http://ark.intel.com/products/75459/Intel-Core-i5-4200U-Processor-3M-Cache-up-to-2_60-GHz?q=i5-4200U

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

Dirk Brandewie <dirk.brandewie@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dirk.brandewie@gmail.com

--- Comment #10 from Dirk Brandewie <dirk.brandewie@gmail.com> ---
Can run "powertop --html sleep 30" and attach powertop.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #11 from Michael Long <harn-solo@gmx.de> ---
Created attachment 140501
  --> https://bugzilla.kernel.org/attachment.cgi?id=140501&action=edit
powertop report on idle system

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

--- Comment #12 from Michael Long <harn-solo@gmx.de> ---
Created attachment 140511
  --> https://bugzilla.kernel.org/attachment.cgi?id=140511&action=edit
powertop report with a grep in a loop

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=77771

Lan Tianyu <tianyu.lan@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tianyu.lan@intel.com
           Assignee|cpufreq@vger.kernel.org     |dirk.brandewie@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.