From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Zhang Rui <rui.zhang@intel.com>
Subject: [PATCH v2.2 4/4] cpufreq: schedutil: Always call driver if CPUFREQ_NEED_UPDATE_LIMITS is set
Date: Thu, 29 Oct 2020 12:12:46 +0100 [thread overview]
Message-ID: <4720046.CcxZZ2xs9j@kreacher> (raw)
In-Reply-To: <1905098.zDJocX6404@kreacher>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Because sugov_update_next_freq() may skip a frequency update even if
the need_freq_update flag has been set for the policy at hand, policy
limits updates may not take effect as expected.
For example, if the intel_pstate driver operates in the passive mode
with HWP enabled, it needs to update the HWP min and max limits when
the policy min and max limits change, respectively, but that may not
happen if the target frequency does not change along with the limit
at hand. In particular, if the policy min is changed first, causing
the target frequency to be adjusted to it, and the policy max limit
is changed later to the same value, the HWP max limit will not be
updated to follow it as expected, because the target frequency is
still equal to the policy min limit and it will not change until
that limit is updated.
To address this issue, modify get_next_freq() to let the driver
callback run if the CPUFREQ_NEED_UPDATE_LIMITS cpufreq driver flag
is set regardless of whether or not the new frequency to set is
equal to the previous one.
Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled")
Reported-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Cc: 5.9+ <stable@vger.kernel.org> # 5.9+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v2.1 -> v2.2:
* Instead of updating need_freq_update if CPUFREQ_NEED_UPDATE_LIMITS is set
in get_next_freq() and checking it again in sugov_update_next_freq(),
check CPUFREQ_NEED_UPDATE_LIMITS directly in sugov_update_next_freq().
* Update the subject.
v2 -> v2.1:
* Fix typo in the subject.
* Make get_next_freq() and sugov_update_next_freq() ignore the
sg_policy->next_freq == next_freq case when CPUFREQ_NEED_UPDATE_LIMITS
is set for the driver.
* Add Tested-by from Rui (this version lets the driver callback run more
often than the v2, so the behavior in the Rui's case doesn't change).
---
kernel/sched/cpufreq_schedutil.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-pm/kernel/sched/cpufreq_schedutil.c
===================================================================
--- linux-pm.orig/kernel/sched/cpufreq_schedutil.c
+++ linux-pm/kernel/sched/cpufreq_schedutil.c
@@ -102,7 +102,8 @@ static bool sugov_should_update_freq(str
static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time,
unsigned int next_freq)
{
- if (sg_policy->next_freq == next_freq)
+ if (sg_policy->next_freq == next_freq &&
+ !cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS))
return false;
sg_policy->next_freq = next_freq;
@@ -161,7 +162,8 @@ static unsigned int get_next_freq(struct
freq = map_util_freq(util, freq, max);
- if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
+ if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update &&
+ !cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS))
return sg_policy->next_freq;
sg_policy->need_freq_update = false;
next prev parent reply other threads:[~2020-10-29 11:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 15:21 [PATCH v2 0/4] cpufreq: intel_pstate: Avoid missing HWP max limit updates with powersave governor Rafael J. Wysocki
2020-10-23 15:35 ` [PATCH v2 1/4] cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS driver flag Rafael J. Wysocki
2020-10-27 3:06 ` Viresh Kumar
2020-10-23 15:35 ` [PATCH v2 2/4] cpufreq: intel_pstate: Avoid missing HWP max updates in passive mode Rafael J. Wysocki
2020-10-27 3:06 ` Viresh Kumar
2020-10-27 8:47 ` Zhang Rui
2020-10-23 15:35 ` [PATCH v2 3/4] cpufreq: Introduce cpufreq_driver_test_flags() Rafael J. Wysocki
2020-10-23 15:36 ` [PATCH v2 4/4] cpufreq: schedutil: Always call drvier if need_freq_update is set Rafael J. Wysocki
2020-10-27 4:25 ` Viresh Kumar
2020-10-27 13:14 ` Rafael J. Wysocki
2020-10-27 8:47 ` Zhang Rui
2020-10-27 15:35 ` [PATCH v2.1 4/4] cpufreq: schedutil: Always call driver " Rafael J. Wysocki
2020-10-28 3:57 ` Viresh Kumar
2020-10-29 10:42 ` Rafael J. Wysocki
2020-10-29 10:54 ` Viresh Kumar
2020-10-29 11:12 ` Rafael J. Wysocki [this message]
2020-10-29 11:23 ` [PATCH v2.2 4/4] cpufreq: schedutil: Always call driver if CPUFREQ_NEED_UPDATE_LIMITS " Viresh Kumar
2020-10-29 11:29 ` Rafael J. Wysocki
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=4720046.CcxZZ2xs9j@kreacher \
--to=rjw@rjwysocki.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rui.zhang@intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=viresh.kumar@linaro.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).