From: Pierre Gondois <pierre.gondois@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>,
linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org,
paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, rafael@kernel.org, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, viresh.kumar@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-pm@vger.kernel.org
Cc: conor.dooley@microchip.com, suagrfillet@gmail.com,
ajones@ventanamicro.com, lftan@kernel.org
Subject: Re: [PATCH 4/4] energy_model: use a fixed reference frequency
Date: Tue, 5 Sep 2023 12:05:30 +0200 [thread overview]
Message-ID: <cd795543-53db-ed14-e9dd-b5738a4f3b9d@arm.com> (raw)
In-Reply-To: <20230901130312.247719-5-vincent.guittot@linaro.org>
Hello Vincent,
I tried the patch-set on a platform using cppc_cpufreq and that has boosting
frequencies,
1-
On such platform, the CPU capacity comes from the CPPC highest_frequency
field. The CPU capacity is set to the capacity of the boosting frequency.
This behaviour is different from DT platforms where the CPU capacity is
updated whenever the boosting mode is enabled (it seems).
Wouldn't it be better to have CPU max capacities set to their boosting
capacity as for CPPC base platforms ? It seems the max frequency is always
available somehow for all the cpufreq drivers with boosting available, i.e.
acpi-cpufreq, amd-pstate, cppc_cpufreq.
2-
On the CPPC based platforms, the per_cpu freq_factor is not used/updated,
meaning that we have:
arch_scale_freq_ref_em()
\-arch_scale_freq_ref()
\-topology_get_freq_ref()
\-per_cpu(freq_factor, cpu) (set to the default value: 1)
and em_cpu_energy()'s ref_freq variable is then set to 1 instead of the max
frequency (leading to a 0 energy computation).
3-
Also just in case, arch_scale_freq_ref_policy() and cpufreq_get_hw_max_freq()
seem to have close (but not identical) purpose,
Regards,
Pierre
On 9/1/23 15:03, Vincent Guittot wrote:
> The last item of a performance domain is not always the performance point
> that has been used to compute CPU's capacity. This can lead to different
> target frequency compared with other part of the system like schedutil and
> would result in wrong energy estimation.
>
> a new arch_scale_freq_ref() is available to return a fixed and coherent
> frequency reference that can be used when computing the CPU's frequency
> for an level of utilization. Use this function when available or fallback
> to the last performance domain item otherwise.
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> include/linux/energy_model.h | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
> index b9caa01dfac4..7ee07be6928e 100644
> --- a/include/linux/energy_model.h
> +++ b/include/linux/energy_model.h
> @@ -204,6 +204,20 @@ struct em_perf_state *em_pd_get_efficient_state(struct em_perf_domain *pd,
> return ps;
> }
>
> +#ifdef arch_scale_freq_ref
> +static __always_inline
> +unsigned long arch_scale_freq_ref_em(int cpu, struct em_perf_domain *pd)
> +{
> + return arch_scale_freq_ref(cpu);
> +}
> +#else
> +static __always_inline
> +unsigned long arch_scale_freq_ref_em(int cpu, struct em_perf_domain *pd)
> +{
> + return pd->table[pd->nr_perf_states - 1].frequency;
> +}
> +#endif
> +
> /**
> * em_cpu_energy() - Estimates the energy consumed by the CPUs of a
> * performance domain
> @@ -224,7 +238,7 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
> unsigned long max_util, unsigned long sum_util,
> unsigned long allowed_cpu_cap)
> {
> - unsigned long freq, scale_cpu;
> + unsigned long freq, ref_freq, scale_cpu;
> struct em_perf_state *ps;
> int cpu;
>
> @@ -241,11 +255,11 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
> */
> cpu = cpumask_first(to_cpumask(pd->cpus));
> scale_cpu = arch_scale_cpu_capacity(cpu);
> - ps = &pd->table[pd->nr_perf_states - 1];
> + ref_freq = arch_scale_freq_ref_em(cpu, pd);
>
> max_util = map_util_perf(max_util);
> max_util = min(max_util, allowed_cpu_cap);
> - freq = map_util_freq(max_util, ps->frequency, scale_cpu);
> + freq = map_util_freq(max_util, ref_freq, scale_cpu);
>
> /*
> * Find the lowest performance state of the Energy Model above the
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-09-05 10:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 13:03 [PATCH 0/4] consolidate and cleanup CPU capacity Vincent Guittot
2023-09-01 13:03 ` [PATCH 1/4] sched: consolidate and cleanup access to CPU's max compute capacity Vincent Guittot
2023-09-05 11:25 ` Peter Zijlstra
2023-09-14 20:45 ` Dietmar Eggemann
2023-09-15 13:20 ` Vincent Guittot
2023-09-01 13:03 ` [PATCH 2/4] topology: add a new arch_scale_freq_reference Vincent Guittot
2023-09-04 12:35 ` Lukasz Luba
2023-09-18 11:23 ` Vincent Guittot
2023-09-14 21:01 ` Dietmar Eggemann
2023-09-21 9:00 ` Ionela Voinescu
2023-09-25 12:06 ` Vincent Guittot
2023-09-01 13:03 ` [PATCH 3/4] cpufreq/schedutil: use a fixed reference frequency Vincent Guittot
2023-09-02 10:57 ` Conor Dooley
2023-09-02 12:49 ` Vincent Guittot
2023-09-05 11:24 ` Peter Zijlstra
2023-09-05 13:50 ` Vincent Guittot
2023-09-21 9:19 ` Ionela Voinescu
2023-09-25 12:06 ` Vincent Guittot
2023-09-01 13:03 ` [PATCH 4/4] energy_model: " Vincent Guittot
2023-09-04 12:40 ` Lukasz Luba
2023-09-05 10:05 ` Pierre Gondois [this message]
2023-09-05 11:33 ` Peter Zijlstra
2023-09-05 13:16 ` Vincent Guittot
2023-09-14 21:07 ` Dietmar Eggemann
2023-09-15 13:35 ` Vincent Guittot
2023-09-18 20:46 ` Dietmar Eggemann
2023-09-21 10:12 ` Ionela Voinescu
2023-09-21 10:12 ` [PATCH 0/4] consolidate and cleanup CPU capacity Ionela Voinescu
2023-09-25 12:05 ` 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=cd795543-53db-ed14-e9dd-b5738a4f3b9d@arm.com \
--to=pierre.gondois@arm.com \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=conor.dooley@microchip.com \
--cc=dietmar.eggemann@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=juri.lelli@redhat.com \
--cc=lftan@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=suagrfillet@gmail.com \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@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).