Re: [PATCH v2 3/3] cpufreq: intel_pstate: hybrid: Adjust energy model rules

[Christian Loehle <christian.loehle@arm.com>]

On 10/16/25 08:48, Yaxiong Tian wrote:
> 在 2025/10/15 21:48, Rafael J. Wysocki 写道:> From: Rafael J. Wysocki <rafael.j.wysocki@intel.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@intel.com>
>> ---
>>   drivers/cpufreq/intel_pstate.c |   37 +++++++++++++++----------------------
>>   1 file changed, 15 insertions(+), 22 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))
>> -		*cost += 2;
>> +	if (hybrid_get_cpu_type(dev->id) == INTEL_CPU_TYPE_ATOM) {
>> +		if (hybrid_has_l3(dev->id)) /* E-core */
>> +			*cost += 2;
>> +	} else { /* P-core */
>> +		*cost += 4;
>> +	}
>>   
>>   	return 0;
>>   }
> 
> Hi Rafael J. Wysocki:
> 
> Is the increment of this cost for different types of CPUs by one instead 
> of two?
> 
> cost by increment of 2:
>           0~40%  40%~60%  60%~80% 80%~100
> LPE-core    2       3        4      5
> E-core      4       5        6      7
> P-core      6       7        8      9
> 
> So, tasks only start being allocated to more powerful CPUs when 
> utilization exceeds 80%, but by that point the system is already in an
>  overloaded state.
> 
> cost by increment of 1:
>           0~40%  40%~60%  60%~80% 80%~100
> LPE-core    2       3        4      5
> E-core      3       4        5      6
> P-core      4       5        6      7
> 
> This situation aligns with the description in your patch.
> 
> The idea of this patch looks good to me.

Agreed if you want the threshold to be 60% for both it should be +1 for l3
and +2 for P-core.
Good catch!