All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH v2 3/3] cpufreq: intel_pstate: Fix intel_pstate_verify_policy()
Date: Wed, 01 Mar 2017 00:11:05 +0100	[thread overview]
Message-ID: <2160593.qOyP8m7930@aspire.rjw.lan> (raw)
In-Reply-To: <2326598.n0dkg1GrdM@aspire.rjw.lan>

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The code added to intel_pstate_verify_policy() by commit 1443ebbacfd7
(cpufreq: intel_pstate: Fix sysfs limits enforcement for performance
policy) should use perf_limits instead of limits, because otherwise
setting global limits via sysfs may affect policies inconsistently.

For example, in the sequence of shell commands below, the
scaling_min_freq attribute for policy1 and policy2 should be
affected in the same way, because scaling_governor is set in
the same way for both of them:

 # cat cpufreq/policy1/scaling_governor
 powersave
 # cat cpufreq/policy2/scaling_governor
 powersave
 # echo performance > cpufreq/policy0/scaling_governor
 # echo 94 > intel_pstate/min_perf_pct
 # cat cpufreq/policy0/scaling_min_freq
 2914000
 # cat cpufreq/policy1/scaling_min_freq
 2914000
 # cat cpufreq/policy2/scaling_min_freq
 800000

The are affected differently, because intel_pstate_verify_policy()
is invoked with limits set to &performance_limits (left behind by
policy0) for policy1 and with limits set to &powersave_limits (left
behind by policy1) for policy2.  Since perf_limits is set to the
set of limits matching the policy being updated, using it instead
of limits fixes the inconsistency.

Fixes: 1443ebbacfd7 (cpufreq: intel_pstate: Fix sysfs limits enforcement for performance policy)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/cpufreq/intel_pstate.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -2208,9 +2208,9 @@ static int intel_pstate_verify_policy(st
 		unsigned int max_freq, min_freq;
 
 		max_freq = policy->cpuinfo.max_freq *
-						limits->max_sysfs_pct / 100;
+					perf_limits->max_sysfs_pct / 100;
 		min_freq = policy->cpuinfo.max_freq *
-						limits->min_sysfs_pct / 100;
+					perf_limits->min_sysfs_pct / 100;
 		cpufreq_verify_within_limits(policy, min_freq, max_freq);
 	}
 

      parent reply	other threads:[~2017-02-28 23:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28 13:13 [PATCH 0/2] cpufreq: intel_pstate: Two fixes related to limis Rafael J. Wysocki
2017-02-28 13:14 ` [PATCH 1/2] cpufreq: intel_pstate: Fix global settings in active mode Rafael J. Wysocki
2017-02-28 22:21   ` Rafael J. Wysocki
2017-02-28 13:16 ` [PATCH 2/2] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy Rafael J. Wysocki
2017-02-28 23:00 ` [PATCH v2 0/3] cpufreq: intel_pstate: Fixes related to limis Rafael J. Wysocki
2017-02-28 23:07   ` [PATCH v2 1/3] cpufreq: intel_pstate: Fix global settings in active mode Rafael J. Wysocki
2017-02-28 23:09   ` [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy Rafael J. Wysocki
2017-03-02 17:18     ` Rafael J. Wysocki
2017-03-02 17:22       ` Rafael J. Wysocki
2017-03-02 22:29     ` [Update][PATCH v3 " Rafael J. Wysocki
2017-03-29 22:01     ` Doug Smythies
2017-03-29 22:16     ` Doug Smythies
2017-03-29 22:17       ` Rafael J. Wysocki
2017-02-28 23:11   ` Rafael J. Wysocki [this message]

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=2160593.qOyP8m7930@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    /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.