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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <61cd69f5-6790-4480-8fe7-77ef763ed82b@arm.com>
Date: Sun, 27 Apr 2025 16:01:32 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
 Linux PM <linux-pm@...r.kernel.org>
Cc: 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 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.

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

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?

[...]