Re: [PATCH 3/3] arm64/sched: Enable CPPC-based asympacking

[Christian Loehle]

On 3/27/26 15:44, Valentin Schneider wrote:
> On 25/03/26 18:13, Christian Loehle wrote:
>> @@ -1753,7 +1760,7 @@ static inline int topology_arch_sched_asym_flags(void)
>>  #ifdef CONFIG_SCHED_SMT
>>  int cpu_smt_flags(void)
>>  {
>> -	return SD_SHARE_CPUCAPACITY | SD_SHARE_LLC;
>> +	return SD_SHARE_CPUCAPACITY | SD_SHARE_LLC | arch_sched_asym_flags();
>>  }
>>  
>>  const struct cpumask *tl_smt_mask(struct sched_domain_topology_level *tl, int cpu)
>> @@ -1765,7 +1772,7 @@ const struct cpumask *tl_smt_mask(struct sched_domain_topology_level *tl, int cp
>>  #ifdef CONFIG_SCHED_CLUSTER
>>  int cpu_cluster_flags(void)
>>  {
>> -	return SD_CLUSTER | SD_SHARE_LLC;
>> +	return SD_CLUSTER | SD_SHARE_LLC | arch_sched_asym_flags();
>>  }
>>  
>>  const struct cpumask *tl_cls_mask(struct sched_domain_topology_level *tl, int cpu)
>> @@ -1777,7 +1784,7 @@ const struct cpumask *tl_cls_mask(struct sched_domain_topology_level *tl, int cp
>>  #ifdef CONFIG_SCHED_MC
>>  int cpu_core_flags(void)
>>  {
>> -	return SD_SHARE_LLC;
>> +	return SD_SHARE_LLC | arch_sched_asym_flags();
>>  }
>>
> 
> So while the binning problem applies to more than one architecture, I'm not
> sure we want this to be generally applied to all topology levels. This is
> /technically/ not a problem since even if a topology level has
> SD_ASYM_PACKING, all CPUs at that level can have the same priority, but
> in that case it's a bit wasteful.
> 
> I don't have any better ideas ATM to keep this arch-specific via
> set_sched_topology(), like how x86 and powerpc handle asym packing.
> 

Right, I think it doesn't make sense at SMT level, but the rest seems
sensible IMO?
It is noted for v2, although unless Andrea sees vastly different results
for Grace than for Vera appetite for this is rather low anyway.