| Message ID | 20231018162540.667646-5-vincent.guittot@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | consolidate and cleanup CPU capacity | expand |
On Wed, Oct 18, 2023 at 06:25:38PM +0200, 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 to get this reference > frequency. > > Energy model is never used without defining arch_scale_freq_ref() but > can be compiled. Define a default arch_scale_freq_ref() returning 0 > in such case. > > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> > Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> > Tested-by: Lukasz Luba <lukasz.luba@arm.com> > > --- > include/linux/energy_model.h | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h > index b9caa01dfac4..1b0c8490d4bd 100644 > --- a/include/linux/energy_model.h > +++ b/include/linux/energy_model.h > @@ -204,6 +204,14 @@ struct em_perf_state *em_pd_get_efficient_state(struct em_perf_domain *pd, > return ps; > } > > +#ifndef arch_scale_freq_ref > +static __always_inline > +unsigned int arch_scale_freq_ref(int cpu) > +{ > + return 0; > +} > +#endif Hmm, did I not see the exact same thing in cpufreq.h two patches ago?
On Wed, Oct 25, 2023 at 01:54:56PM +0200, Peter Zijlstra wrote: Also, can we pretty please not cross-post to moderated lists, that's rude. Rafael, can you please mark this acpica-devel crap as moderated in MAINTAINERS so that it can be auto-magically excluded from receiving mail?
On Wed, Oct 25, 2023 at 2:11 PM Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, Oct 25, 2023 at 01:54:56PM +0200, Peter Zijlstra wrote: > > Also, can we pretty please not cross-post to moderated lists, that's > rude. > > Rafael, can you please mark this acpica-devel crap as moderated in > MAINTAINERS so that it can be auto-magically excluded from receiving > mail? I'm actually not sure why it is moderated. I'll see if that can be changed.
On Wed, 25 Oct 2023 at 13:55, Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, Oct 18, 2023 at 06:25:38PM +0200, 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 to get this reference > > frequency. > > > > Energy model is never used without defining arch_scale_freq_ref() but > > can be compiled. Define a default arch_scale_freq_ref() returning 0 > > in such case. > > > > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> > > Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> > > Tested-by: Lukasz Luba <lukasz.luba@arm.com> > > > > --- > > include/linux/energy_model.h | 14 +++++++++++--- > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h > > index b9caa01dfac4..1b0c8490d4bd 100644 > > --- a/include/linux/energy_model.h > > +++ b/include/linux/energy_model.h > > @@ -204,6 +204,14 @@ struct em_perf_state *em_pd_get_efficient_state(struct em_perf_domain *pd, > > return ps; > > } > > > > +#ifndef arch_scale_freq_ref > > +static __always_inline > > +unsigned int arch_scale_freq_ref(int cpu) > > +{ > > + return 0; > > +} > > +#endif > > Hmm, did I not see the exact same thing in cpufreq.h two patches ago? Probably, this has been added because of error returned by some allyes/randconfig on x86 > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h index b9caa01dfac4..1b0c8490d4bd 100644 --- a/include/linux/energy_model.h +++ b/include/linux/energy_model.h @@ -204,6 +204,14 @@ struct em_perf_state *em_pd_get_efficient_state(struct em_perf_domain *pd, return ps; } +#ifndef arch_scale_freq_ref +static __always_inline +unsigned int arch_scale_freq_ref(int cpu) +{ + return 0; +} +#endif + /** * em_cpu_energy() - Estimates the energy consumed by the CPUs of a * performance domain @@ -224,7 +232,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 +249,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(cpu); 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