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

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

On 9/9/26 7:48 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Wakeup path funneling to lowest-ID preferred CPU bypassing CFS load balancing
> --
> 
> commit 2b5645419bf5356450334e7129102cfed3b5f5bf
> Author: Shrikanth Hegde <sshegde@linux.ibm.com>
> 
> sched/core: Try to use a preferred CPU in is_cpu_allowed
> 
> When possible, try to choose a preferred CPU to maintain user affinities
> when preferred CPUs change. Update is_cpu_allowed() to ensure wakeups
> happen on preferred CPUs.
> 
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index a689a0cea4ebe..b4ef2e92d786b 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
> [ ... ]
>> @@ -2519,8 +2536,12 @@ static inline bool is_cpu_allowed(struct task_struct *p, int cpu)
>>   		return cpu_online(cpu);
>>   
>>   	/* Non kernel threads are not allowed during either online or offline. */
>> -	if (!(p->flags & PF_KTHREAD))
>> +	if (!(p->flags & PF_KTHREAD)) {
>> +		/* Try to use preferred CPU if task's affinity allows */
>> +		if (task_can_sched_on_preferred(cpu, p))
>> +			return false;
> 
> [Severity: High]
> Does returning false here for non-preferred CPUs cause FAIR wakeups to funnel
> into a single CPU and bypass CFS load balancing?
> 
> When a FAIR task wakes up, select_task_rq_fair() and select_idle_sibling()
> search for an idle CPU. Because select_idle_sibling() remains unaware of
> cpu_preferred_mask, it can actively select an idle non-preferred CPU.
> 
> When this selected CPU is checked after the scheduler class's placement
> decision, is_cpu_allowed() will now hard-reject it. This forces
> select_task_rq() into the slow path:
> 
>      cpu = p->sched_class->select_task_rq(p, task_cpu(p), wake_flags);
>      if (unlikely(!is_cpu_allowed(p, cpu)))
>          cpu = select_fallback_rq(task_cpu(p), p);
> 
> Because select_fallback_rq() sequentially searches the mask:
> 
>      for_each_cpu(dest_cpu, nodemask) {
>          if (is_cpu_allowed(p, dest_cpu))
>              return dest_cpu;
>      }
> 
> Will this cause waking tasks to be dumped repeatedly onto the lowest-ID
> preferred CPU, creating massive runqueue hotspots?
> 

This is expected by design and existing load balancer will spread the task out
post the wakeup among preferred CPUs.

Since effectively workload has lesser CPUs compared to original, preferred CPUs
can be overloaded with more than one task per rq. That's also expected by design.

I don't see it as major concern.

>>   		return cpu_active(cpu);
>> +	}
>>   
>>   	/* KTHREAD_IS_PER_CPU is always allowed. */
>>   	if (kthread_is_per_cpu(p))
>