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

[Shrikanth Hegde]

On 9/9/26 7:48 PM, sashiko-...@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 <sshe...@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))