Re: [PATCH v13 06/13] sched/core: Try to use a preferred CPU in is_cpu_allowed

[Shrikanth Hegde <sshegde@linux.ibm.com>]

Hi Peter. Thanks for looking into the patches.

On 9/25/26 1:13 PM, Peter Zijlstra wrote:
> On Wed, Sep 09, 2026 at 07:26:10PM +0530, Shrikanth Hegde wrote:
> 
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index a689a0cea4eb..b4ef2e92d786 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2504,6 +2504,23 @@ static inline bool rq_has_pinned_tasks(struct rq *rq)
>>   	return rq->nr_pinned;
>>   }
>>   
>> +static inline bool task_can_sched_on_preferred(int cpu, struct task_struct *p)
> 
> (somehow those arguments feel backwards)
> 
>> +{
>> +	if (cpu_preferred(cpu))
>> +		return false;
> 
> FWIW, this reads very weird. task_can_sched_on_preferred() returning
> false when task is on a preferred cpu.
> 

How about below signature?

static inline bool task_can_migrate_to_preferred(struct task_struct *p, int cpu)

> The question really is more like: can we migrate to a preferred CPU, and
> in that context it makes more sense. No point in migrating if we are
> already on one.
> 
> Perhaps a comment on top of the function can clarify?
> 

Above new function name is self explanatory IMHO.

>> +	/* Only FAIR tasks honor preferred CPU state */
>> +	if (unlikely(p->sched_class != &fair_sched_class))
>> +		return false;
>> +
>> +	/* Ignore preferred state if task affinity is changing */
>> +	if (unlikely(!cpumask_test_cpu(task_cpu(p), p->cpus_ptr)))
>> +		return false;
>> +
>> +	return cpumask_intersects_and(p->cpus_ptr, cpu_preferred_mask,
>> +				      task_cpu_possible_mask(p));
>> +}