cpufreq.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: cpufreq@vger.kernel.org
Subject: [Bug 64271] New: Intel Pstate driver - "kick" code is not needed
Date: Sat, 02 Nov 2013 22:17:51 +0000	[thread overview]
Message-ID: <bug-64271-12968@https.bugzilla.kernel.org/> (raw)

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

            Bug ID: 64271
           Summary: Intel Pstate driver - "kick" code is not needed
           Product: Power Management
           Version: 2.5
    Kernel Version: 3.12rc7
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: cpufreq
          Assignee: cpufreq@vger.kernel.org
          Reporter: dsmythies@telus.net
        Regression: No

There is code in the routine intel_pstate_timer_func to "kick" the CPU out of
the minimum pstate.

The code was added back when several things were not working properly with the
driver. It was added due to a "ping-pong" issue uncovered by the Phoronix test
suite ffpmeg test. I have tried extensively to recreate the issue with the
"kick" code removed and have not been able to. I am unable to detect any
difference with the ffmpeg test between the normal code and code with the "kick
removed" The assertion is that the "kick" code is not required and should be
deleted.

This bug has been extracted from bug 59481 which ended up discussing a few
tangent issues. The main issue was solved and the bug closed. Now I am
following up on some of the tangent issues.

I am saying the kick portion of this code can be removed because it serves no
purpose and makes the code harder to read and understand:

static void intel_pstate_timer_func(unsigned long __data)
{
        struct cpudata *cpu = (struct cpudata *) __data;

        intel_pstate_sample(cpu);
        intel_pstate_adjust_busy_pstate(cpu);

        if (cpu->pstate.current_pstate == cpu->pstate.min_pstate) {
                cpu->min_pstate_count++;
                if (!(cpu->min_pstate_count % 5)) {
                        intel_pstate_set_pstate(cpu, cpu->pstate.max_pstate);
                }
        } else
                cpu->min_pstate_count = 0;

        intel_pstate_set_sample_time(cpu);
}

Where this was left on 2013.07.18 with Dirk Brandewie was that he wanted to go
back and verify in his test environment. Which, of course, should be done.

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

             reply	other threads:[~2013-11-02 22:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-02 22:17 bugzilla-daemon [this message]
2013-11-03 21:13 ` [Bug 64271] Intel Pstate driver - "kick" code is not needed bugzilla-daemon
2013-11-04 16:17 ` bugzilla-daemon
2013-11-04 16:42 ` bugzilla-daemon
2013-11-04 17:01 ` bugzilla-daemon
2013-11-05 23:12 ` bugzilla-daemon
2014-04-15  6:30 ` bugzilla-daemon
2014-04-15  6:30 ` 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-64271-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).