[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB8ipk_5TjUTrZ-nrGAwYMugLJFF72MvvRDzPJqaCayNwCm1wg@mail.gmail.com>
Date: Tue, 19 Dec 2023 12:03:28 +0800
From: Xuewen Yan <xuewen.yan94@...il.com>
To: Qais Yousef <qyousef@...alina.io>
Cc: Lukasz Luba <lukasz.luba@....com>, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, rafael@...nel.org, dietmar.eggemann@....com,
rui.zhang@...el.com, amit.kucheria@...durent.com, amit.kachhap@...il.com,
daniel.lezcano@...aro.org, viresh.kumar@...aro.org, len.brown@...el.com,
pavel@....cz, mhiramat@...nel.org, wvw@...gle.com
Subject: Re: [PATCH v5 09/23] PM: EM: Use runtime modified EM for CPUs energy
estimation in EAS
On Mon, Dec 18, 2023 at 1:59 AM Qais Yousef <qyousef@...alina.io> wrote:
>
> On 11/29/23 11:08, Lukasz Luba wrote:
> > The new Energy Model (EM) supports runtime modification of the performance
> > state table to better model the power used by the SoC. Use this new
> > feature to improve energy estimation and therefore task placement in
> > Energy Aware Scheduler (EAS).
>
> nit: you moved the code to use the new runtime em table instead of the one
> parsed at boot.
>
> >
> > Signed-off-by: Lukasz Luba <lukasz.luba@....com>
> > ---
> > include/linux/energy_model.h | 16 ++++++++++++----
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
> > index 1e618e431cac..94a77a813724 100644
> > --- a/include/linux/energy_model.h
> > +++ b/include/linux/energy_model.h
> > @@ -238,6 +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)
> > {
> > + struct em_perf_table *runtime_table;
> > unsigned long freq, scale_cpu;
> > struct em_perf_state *ps;
> > int cpu, i;
> > @@ -255,7 +256,14 @@ 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];
> > +
> > + /*
> > + * No rcu_read_lock() since it's already called by task scheduler.
> > + * The runtime_table is always there for CPUs, so we don't check.
> > + */
>
> WARN_ON(rcu_read_lock_held()) instead?
I agree, or SCHED_WARN_ON(!rcu_read_lock_held()) ?
>
>
> Cheers
>
> --
> Qais Yousef
>
> > + runtime_table = rcu_dereference(pd->runtime_table);
> > +
> > + ps = &runtime_table->state[pd->nr_perf_states - 1];
> >
> > max_util = map_util_perf(max_util);
> > max_util = min(max_util, allowed_cpu_cap);
> > @@ -265,9 +273,9 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
> > * Find the lowest performance state of the Energy Model above the
> > * requested frequency.
> > */
> > - i = em_pd_get_efficient_state(pd->table, pd->nr_perf_states, freq,
> > - pd->flags);
> > - ps = &pd->table[i];
> > + i = em_pd_get_efficient_state(runtime_table->state, pd->nr_perf_states,
> > + freq, pd->flags);
> > + ps = &runtime_table->state[i];
> >
> > /*
> > * The capacity of a CPU in the domain at the performance state (ps)
> > --
> > 2.25.1
> >
>
Powered by blists - more mailing lists