All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sultan Alsawaf <sultan@kerneltoast.com>
Cc: "Sultan Alsawaf (unemployed)" <sultan@kerneltoast.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 1/2] cpufreq: schedutil: Fix superfluous updates caused by need_freq_update
Date: Wed, 11 Dec 2024 17:57:32 -0800	[thread overview]
Message-ID: <20241212015734.41241-2-sultan@kerneltoast.com> (raw)
In-Reply-To: <20241212015734.41241-1-sultan@kerneltoast.com>

From: "Sultan Alsawaf (unemployed)" <sultan@kerneltoast.com>

A redundant frequency update is only truly needed when there is a policy
limits change with a driver that specifies CPUFREQ_NEED_UPDATE_LIMITS.

In spite of that, drivers specifying CPUFREQ_NEED_UPDATE_LIMITS receive a
frequency update _all the time_, not just for a policy limits change,
because need_freq_update is never cleared.

Furthermore, ignore_dl_rate_limit()'s usage of need_freq_update also leads
to a redundant frequency update, regardless of whether or not the driver
specifies CPUFREQ_NEED_UPDATE_LIMITS, when the next chosen frequency is the
same as the current one.

Fix the superfluous updates by only honoring CPUFREQ_NEED_UPDATE_LIMITS
when there's a policy limits change, and clearing need_freq_update when a
requisite redundant update occurs.

This is neatly achieved by moving up the CPUFREQ_NEED_UPDATE_LIMITS test
and instead setting need_freq_update to false in sugov_update_next_freq().

Signed-off-by: Sultan Alsawaf (unemployed) <sultan@kerneltoast.com>
---
 kernel/sched/cpufreq_schedutil.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 28c77904ea74..e51d5ce730be 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -83,7 +83,7 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time)
 
 	if (unlikely(sg_policy->limits_changed)) {
 		sg_policy->limits_changed = false;
-		sg_policy->need_freq_update = true;
+		sg_policy->need_freq_update = cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS);
 		return true;
 	}
 
@@ -96,7 +96,7 @@ static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time,
 				   unsigned int next_freq)
 {
 	if (sg_policy->need_freq_update)
-		sg_policy->need_freq_update = cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS);
+		sg_policy->need_freq_update = false;
 	else if (sg_policy->next_freq == next_freq)
 		return false;
 
-- 
2.47.1


  reply	other threads:[~2024-12-12  1:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12  1:57 [PATCH 2/2] cpufreq: schedutil: Ignore rate limit when scaling up with FIE present Sultan Alsawaf
2024-12-12  1:57 ` Sultan Alsawaf [this message]
2024-12-12 13:24   ` [PATCH 1/2] cpufreq: schedutil: Fix superfluous updates caused by need_freq_update Christian Loehle
2024-12-14  2:35     ` Sultan Alsawaf (unemployed)
2024-12-18 15:10     ` Rafael J. Wysocki
2025-04-08  8:59   ` Stephan Gerhold
2025-04-08 15:22     ` Sultan Alsawaf
2025-04-08 16:48       ` Stephan Gerhold
2025-04-09 11:25         ` Xuewen Yan
2025-04-09 11:48           ` Xuewen Yan
2025-04-10  1:49             ` Sultan Alsawaf
2025-04-10  2:06               ` Xuewen Yan
2025-04-10  2:08                 ` Sultan Alsawaf
2025-04-10  2:13                   ` Xuewen Yan
2025-04-10  2:22                     ` Sultan Alsawaf
2025-04-10  2:30                       ` Xuewen Yan
2025-04-10  2:33                         ` Sultan Alsawaf
2025-04-10  2:42                           ` Xuewen Yan
2025-04-10  1:52         ` Sultan Alsawaf
2025-04-10 19:16     ` Rafael J. Wysocki
2024-12-12 12:06 ` [PATCH 2/2] cpufreq: schedutil: Ignore rate limit when scaling up with FIE present Christian Loehle
2024-12-14  2:15   ` Sultan Alsawaf (unemployed)

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=20241212015734.41241-2-sultan@kerneltoast.com \
    --to=sultan@kerneltoast.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vschneid@redhat.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.