Re: [PATCH v3 15/21] sched/cache: Disable cache aware scheduling for processes with high thread counts

[Madadi Vineeth Reddy]

On 19/02/26 22:22, Peter Zijlstra wrote:
> On Wed, Feb 18, 2026 at 11:24:05PM +0530, Madadi Vineeth Reddy wrote:
> 
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index d1145997b88d..86b6b08e7e1e 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -1223,6 +1223,19 @@ static inline bool valid_llc_buf(struct sched_domain *sd,
>>>  	return valid_llc_id(id);
>>>  }
>>>  
>>> +static bool exceed_llc_nr(struct mm_struct *mm, int cpu)
>>> +{
>>> +	int smt_nr = 1;
>>> +
>>> +#ifdef CONFIG_SCHED_SMT
>>> +	if (sched_smt_active())
>>> +		smt_nr = cpumask_weight(cpu_smt_mask(cpu));
>>> +#endif
>>> +
>>> +	return !fits_capacity((mm->sc_stat.nr_running_avg * smt_nr),
>>> +			per_cpu(sd_llc_size, cpu));
>>
>>
>> On Power10/Power11 with SMT4 and LLC size of 4, this check
>> effectively disables cache-aware scheduling for any process.
>>
>> I raised this point in v1 as well. Increasing the threshold
>> doesn't seem like a viable solution either, as that would regress
>> hackbench/ebizzy.
>>
>> Is there a way to make this useful for architectures with small LLC
>> sizes? One possible approach we were exploring is to have LLC at a
>> hemisphere level that comprise multiple SMT4 cores.
> 
> One way forward would be to use a llc-mask instead of a single llc value
> for preference. I think this got mentioned before, and I think it makes
> sense to do this later.
> 
> But once you can have a 'few' LLCs as preference, this constraint
> becomes a little easier.

Yes, that makes sense. Spanning the llc-mask across multiple cores
in a hemisphere for preference would relax this condition.

We will explore how this can be incorporated. Thanks for taking a
look.

Thanks,
Vineeth