From: Lukasz Luba <lukasz.luba@arm.com>
To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
rafael@kernel.org
Cc: lukasz.luba@arm.com, viresh.kumar@linaro.org,
dietmar.eggemann@arm.com, vincent.guittot@linaro.org,
saravanak@google.com, wusamuel@google.com,
isaacmanjarres@google.com, kernel-team@android.com,
juri.lelli@redhat.com, peterz@infradead.org, mingo@redhat.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de
Subject: [PATCH v2 2/2] cpufreq: schedutil: Optimize operations with single max CPU capacity
Date: Wed, 7 Dec 2022 10:17:05 +0000 [thread overview]
Message-ID: <20221207101705.9460-3-lukasz.luba@arm.com> (raw)
In-Reply-To: <20221207101705.9460-1-lukasz.luba@arm.com>
The max CPU capacity is the same for all CPUs sharing frequency domain
and thus 'policy' object. There is a way to avoid heavy operations
in a loop for each CPU by leveraging this knowledge. Thus, simplify
the looping code in the sugov_next_freq_shared() and drop heavy
multiplications. Instead, use simple max() to get the highest utilization
from these CPUs. This is useful for platforms with many (4 or 6) little
CPUs.
The max CPU capacity must be fetched every time we are called, due to
difficulties during the policy setup, where we are not able to get the
normalized CPU capacity at the right time.
The stored value in sugov_policy::max is also than used in
sugov_iowait_apply() to calculate the right boost. Thus, that field is
useful to have in that sugov_policy struct.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
kernel/sched/cpufreq_schedutil.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index c19d6de67b7a..f9881f3d9488 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -158,10 +158,8 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
static void sugov_get_util(struct sugov_cpu *sg_cpu)
{
- struct sugov_policy *sg_policy = sg_cpu->sg_policy;
struct rq *rq = cpu_rq(sg_cpu->cpu);
- sg_policy->max = arch_scale_cpu_capacity(sg_cpu->cpu);
sg_cpu->bw_dl = cpu_bw_dl(rq);
sg_cpu->util = effective_cpu_util(sg_cpu->cpu, cpu_util_cfs(sg_cpu->cpu),
FREQUENCY_UTIL, NULL);
@@ -317,6 +315,8 @@ static inline void ignore_dl_rate_limit(struct sugov_cpu *sg_cpu)
static inline bool sugov_update_single_common(struct sugov_cpu *sg_cpu,
u64 time, unsigned int flags)
{
+ struct sugov_policy *sg_policy = sg_cpu->sg_policy;
+
sugov_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
@@ -325,6 +325,9 @@ static inline bool sugov_update_single_common(struct sugov_cpu *sg_cpu,
if (!sugov_should_update_freq(sg_cpu->sg_policy, time))
return false;
+ /* Fetch the latest CPU capcity to avoid stale data */
+ sg_policy->max = arch_scale_cpu_capacity(sg_cpu->cpu);
+
sugov_get_util(sg_cpu);
sugov_iowait_apply(sg_cpu, time);
@@ -414,25 +417,22 @@ static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 time)
{
struct sugov_policy *sg_policy = sg_cpu->sg_policy;
struct cpufreq_policy *policy = sg_policy->policy;
- unsigned long util = 0, max = 1;
+ unsigned long util = 0;
unsigned int j;
+ /* Fetch the latest CPU capcity to avoid stale data */
+ sg_policy->max = arch_scale_cpu_capacity(sg_cpu->cpu);
+
for_each_cpu(j, policy->cpus) {
struct sugov_cpu *j_sg_cpu = &per_cpu(sugov_cpu, j);
- unsigned long j_util, j_max;
sugov_get_util(j_sg_cpu);
sugov_iowait_apply(j_sg_cpu, time);
- j_util = j_sg_cpu->util;
- j_max = j_sg_cpu->max;
- if (j_util * max > j_max * util) {
- util = j_util;
- max = j_max;
- }
+ util = max(j_sg_cpu->util, util);
}
- return get_next_freq(sg_policy, util, max);
+ return get_next_freq(sg_policy, util, sg_policy->max);
}
static void
--
2.17.1
next prev parent reply other threads:[~2022-12-07 10:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 10:17 [PATCH v2 0/2] cpufreq: schedutil: Optimize operations in hot path frequency switch Lukasz Luba
2022-12-07 10:17 ` [PATCH v2 1/2] cpufreq: schedutil: Introduce single max CPU capacity for freqency domain Lukasz Luba
2022-12-08 3:57 ` Viresh Kumar
2022-12-07 10:17 ` Lukasz Luba [this message]
2022-12-08 4:09 ` [PATCH v2 2/2] cpufreq: schedutil: Optimize operations with single max CPU capacity Viresh Kumar
2022-12-08 8:43 ` Lukasz Luba
2022-12-08 8:37 ` Vincent Guittot
2022-12-08 10:06 ` Lukasz Luba
2022-12-08 10:31 ` Vincent Guittot
2022-12-08 10:56 ` Lukasz Luba
2022-12-08 13:20 ` Vincent Guittot
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=20221207101705.9460-3-lukasz.luba@arm.com \
--to=lukasz.luba@arm.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=isaacmanjarres@google.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.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=saravanak@google.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=wusamuel@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®