linux-kernel - Re: [PATCH v3 3/3] cpufreq: intel_pstate: hybrid: Adjust energy model rules

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] [day] [month] [year] [list]

Message-ID: <17d59056-d613-40a5-a2d1-9a03f8c3ab12@kylinos.cn>
Date: Fri, 17 Oct 2025 09:15:38 +0800
From: Yaxiong Tian <tianyaxiong@...inos.cn>
To: "Rafael J. Wysocki" <rafael@...nel.org>,
 Linux PM <linux-pm@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Lukasz Luba <lukasz.luba@....com>,
 Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
 Dietmar Eggemann <dietmar.eggemann@....com>,
 Christian Loehle <christian.loehle@....com>
Subject: Re: [PATCH v3 3/3] cpufreq: intel_pstate: hybrid: Adjust energy model
 rules


在 2025/10/17 00:22, Rafael J. Wysocki 写道:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> Instead of using HWP-to-frequency scaling factors for computing cost
> coefficients in the energy model used on hybrid systems, which is
> fragile, rely on CPU type information that is easily accessible now and
> the information on whether or not L3 cache is present for this purpose.
>
> This also allows the cost coefficients for P-cores to be adjusted so
> that they start to be populated somewhat earlier (that is, before
> E-cores are loaded up to their full capacity).
>
> In addition to the above, replace an inaccurate comment regarding the
> reason why the freq value is added to the cost in hybrid_get_cost().
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@....com>
> ---
>
> v2 -> v3:
>     * Reduce cost differences between CPU types by 1 (Tian, Christian)
>     * Add a tag from Dietmar
>
> Note: The other patches in the series have not changed.
>
> v1 -> v2: New patch
>
> ---
>   drivers/cpufreq/intel_pstate.c |   35 ++++++++++++++---------------------
>   1 file changed, 14 insertions(+), 21 deletions(-)
>
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -933,11 +933,8 @@ static int hybrid_active_power(struct de
>   			       unsigned long *freq)
>   {
>   	/*
> -	 * Create "utilization bins" of 0-40%, 40%-60%, 60%-80%, and 80%-100%
> -	 * of the maximum capacity such that two CPUs of the same type will be
> -	 * regarded as equally attractive if the utilization of each of them
> -	 * falls into the same bin, which should prevent tasks from being
> -	 * migrated between them too often.
> +	 * Create four "states" corresponding to 40%, 60%, 80%, and 100% of the
> +	 * full capacity.
>   	 *
>   	 * For this purpose, return the "frequency" of 2 for the first
>   	 * performance level and otherwise leave the value set by the caller.
> @@ -970,26 +967,22 @@ static bool hybrid_has_l3(unsigned int c
>   static int hybrid_get_cost(struct device *dev, unsigned long freq,
>   			   unsigned long *cost)
>   {
> -	struct pstate_data *pstate = &all_cpu_data[dev->id]->pstate;
> -
> +	/* Facilitate load balancing between CPUs of the same type. */
> +	*cost = freq;
>   	/*
> -	 * The smaller the perf-to-frequency scaling factor, the larger the IPC
> -	 * ratio between the given CPU and the least capable CPU in the system.
> -	 * Regard that IPC ratio as the primary cost component and assume that
> -	 * the scaling factors for different CPU types will differ by at least
> -	 * 5% and they will not be above INTEL_PSTATE_CORE_SCALING.
> +	 * Adjust the cost depending on CPU type.
>   	 *
> -	 * Add the freq value to the cost, so that the cost of running on CPUs
> -	 * of the same type in different "utilization bins" is different.
> -	 */
> -	*cost = div_u64(100ULL * INTEL_PSTATE_CORE_SCALING, pstate->scaling) + freq;
> -	/*
> -	 * Increase the cost slightly for CPUs able to access L3 to avoid
> -	 * touching it in case some other CPUs of the same type can do the work
> -	 * without it.
> +	 * The idea is to start loading up LPE-cores before E-cores and start
> +	 * to populate E-cores when LPE-cores are utilized above 60% of the
> +	 * capacity.  Similarly, P-cores start to be populated when E-cores are
> +	 * utilized above 60% of the capacity.
>   	 */
> -	if (hybrid_has_l3(dev->id))
> +	if (hybrid_get_cpu_type(dev->id) == INTEL_CPU_TYPE_ATOM) {
> +		if (hybrid_has_l3(dev->id)) /* E-core */
> +			*cost += 1;
> +	} else { /* P-core */
>   		*cost += 2;
> +	}
>   
>   	return 0;
>   }

LGTM
Reviewed-by: Yaxiong Tian <tianyaxiong@...inos.cn>