linux-kernel - Re: [RFT][PATCH v1 5/8] PM: EM: Introduce em_adjust_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0h=wR464YqDEesnm3QscJ4UBy8CX0ixZV6QsY0DS22E8A@mail.gmail.com>
Date: Wed, 30 Apr 2025 21:23:04 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Dietmar Eggemann <dietmar.eggemann@....com>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM <linux-pm@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Lukasz Luba <lukasz.luba@....com>, 
	Peter Zijlstra <peterz@...radead.org>, 
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, 
	Morten Rasmussen <morten.rasmussen@....com>, Vincent Guittot <vincent.guittot@...aro.org>, 
	Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>, 
	Pierre Gondois <pierre.gondois@....com>, Christian Loehle <christian.loehle@....com>
Subject: Re: [RFT][PATCH v1 5/8] PM: EM: Introduce em_adjust_cpu_capacity()

On Sun, Apr 27, 2025 at 4:07 PM Dietmar Eggemann
<dietmar.eggemann@....com> wrote:
>
> On 16/04/2025 20:06, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > Add a function for updating the Energy Model for a CPU after its
> > capacity has changed, which subsequently will be used by the
> > intel_pstate driver.
> >
> > An EM_PERF_DOMAIN_ARTIFICIAL check is added to em_adjust_new_capacity()
> > to prevent it from calling em_compute_costs() for an "artificial" perf
> > domain with a NULL cb parameter which would cause it to crash.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > Reviewed-by: Lukasz Luba <lukasz.luba@....com>
> > ---
> >
> > v0.3 -> v1:
> >      * Added R-by from Lukasz.
> >
> > ---
> >  include/linux/energy_model.h |    2 ++
> >  kernel/power/energy_model.c  |   28 ++++++++++++++++++++++++----
> >  2 files changed, 26 insertions(+), 4 deletions(-)
> >
> > --- a/include/linux/energy_model.h
> > +++ b/include/linux/energy_model.h
> > @@ -179,6 +179,7 @@
> >  int em_dev_update_chip_binning(struct device *dev);
> >  int em_update_performance_limits(struct em_perf_domain *pd,
> >               unsigned long freq_min_khz, unsigned long freq_max_khz);
> > +void em_adjust_cpu_capacity(unsigned int cpu);
> >  void em_rebuild_sched_domains(void);
> >
> >  /**
> > @@ -405,6 +406,7 @@
> >  {
> >       return -EINVAL;
> >  }
> > +static inline void em_adjust_cpu_capacity(unsigned int cpu) {}
> >  static inline void em_rebuild_sched_domains(void) {}
> >  #endif
> >
> > --- a/kernel/power/energy_model.c
> > +++ b/kernel/power/energy_model.c
> > @@ -698,10 +698,12 @@
> >  {
> >       int ret;
> >
> > -     ret = em_compute_costs(dev, em_table->state, NULL, pd->nr_perf_states,
> > -                            pd->flags);
> > -     if (ret)
> > -             goto free_em_table;
> > +     if (!(pd->flags & EM_PERF_DOMAIN_ARTIFICIAL)) {
>
> This looks weird to me. How can an artificial EM ever have a non-ZERO
> em_data_callback here?
>
> There is already EM_PERF_DOMAIN_ARTIFICIAL specific handling in
> em_compute_costs(). Which probably works well for the
> em_create_perf_table() call-site.

Yes, but that one doesn't pass a NULL cb pointer to it.

> Will there be cases for Hybrid CPU EM's in which 'em_max_perf !=
> cpu_capacity':

When the capacity is updated, the EM needs to be updated accordingly,
which is why the new function is being added.

> em_adjust_new_capacity()
>
>   if (em_max_perf == cpu_capacity)
>     return
>
>   em_recalc_and_update()
>     em_compute_costs()
>
> so that em_compute_costs() might be called?
>
> Maybe:
>
> @@ -233,11 +237,17 @@ static int em_compute_costs(struct device *dev,
> struct em_perf_state *table,
>         unsigned long prev_cost = ULONG_MAX;
>         int i, ret;
>
> +       if (!cb && (flags & EM_PERF_DOMAIN_ARTIFICIAL))
> +               return 0;
>
> is somehow clearer in this case?

This would work, but I prefer my version because it does one check
less and it does the check directly in em_recalc_and_update(), so it
is clear that this doesn't call em_compute_costs() for artificial PDs
at all.