All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: cpufreq@vger.kernel.org
Subject: [Bug 77771] New: Intel P-State: Constantly changing CPU frequencies on idle system.
Date: Fri, 13 Jun 2014 05:49:56 +0000	[thread overview]
Message-ID: <bug-77771-12968@https.bugzilla.kernel.org/> (raw)

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.

             reply	other threads:[~2014-06-13  5:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-13  5:49 bugzilla-daemon [this message]
2014-06-13  6:20 ` [Bug 77771] Intel P-State: Constantly changing CPU frequencies on idle system bugzilla-daemon
2014-06-13  8:18 ` bugzilla-daemon
2014-06-13  9:09 ` bugzilla-daemon
2014-06-15  0:44 ` bugzilla-daemon
2014-06-16 19:15 ` bugzilla-daemon
2014-06-16 19:19 ` bugzilla-daemon
2014-06-17  1:46 ` bugzilla-daemon
2014-06-17  3:34 ` bugzilla-daemon
2014-06-19 16:25 ` bugzilla-daemon
2014-06-19 16:34 ` bugzilla-daemon
2014-06-20 16:10 ` bugzilla-daemon
2014-06-20 16:11 ` bugzilla-daemon
2014-06-23  8:08 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-77771-12968@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=cpufreq@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.