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

[sashiko-bot@kernel.org]

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?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909135617.871006-1-sshegde@linux.ibm.com?part=6