Re: [PATCH v3] sched/fair: Prefer waker CPU for non-SMT reciprocal sync wakeups

Hello Srikanth,

Thank you for the review.

On Mon, 3 Aug 2026, Shrikanth Hegde wrote:

> I think we need to think this on the policy notion rather than a usecase 
> specific.
> These are api's available to other susystems to make specific call based on 
> its
> understand of its requirement. i.e
> wake_up_interruptible_sync_poll
> vs
> wake_up, wake_up_interruptible
>

Agreed. I do not want this patch to define a new generic meaning 
for WF_SYNC. My view is that WF_SYNC should remain a hint that the waker 
is expected to stop running soon and not a hard request for specific CPU.

> If we look at __wake_up_sync*, It says,
>
> /**
> * __wake_up_sync_key - wake up threads blocked on a waitqueue.
> * @wq_head: the waitqueue
> * @mode: which threads
> * @key: opaque value to be passed to wakeup targets
> *
> * The sync wakeup differs that the waker knows that it will schedule
> * away soon, so while the target thread will be woken up, it will not
> * be migrated to another CPU - ie. the two threads are 'synchronized'
> * with each other. This can prevent needless bouncing between CPUs.
> *

This comment reads stronger than what the CFS wakeup path currently does. 
In select_task_rq_fair(), WF_SYNC is an input to wake_affine_idle() and 
wake_affine_weight(), where it can bias the target toward the waker CPU. 
That target is still passed to select_idle_sibling(), which can choose 
another idle, recent or previous CPU.

So callers already cannot rely on wake_up*_sync() to mean exact CPU 
placement. They provide the hint and the scheduler maps it to a placement 
based on the current topology, affinity, capacity, idle state and load.

> So, with that, we use introduce the notion that, scheduler wakeup will honor
> the sync behaviour based on underlying arch/hw, how will callers ever
> know. For example, same SMT system can have all its siblings off, and now it
> is !smt system.
>
> There is already use/abuse of sync api in Networking staff.
> A recent discussion on it,
> https://lore.kernel.org/all/[email protected]/
> I am assuming there would be more.

Sure, I agree WF_SYNC alone is too broad to strengthen globally.

For v4, I plan to make the patch narrower than v3. The check will stay in 
the wake affine path, but it will run after wake_affine(). It will only 
return the waker CPU if wake_affine() already selected that CPU. It will 
also still check the reciprocal last_wakee/wake_wide() pattern, an 
otherwise empty waker rq and task_fits_cpu() on asym capacity systems.

>
> So, What should sync wakeup should do vs non-sync wakeup?
> - Should it chose waker's CPU if waker is the only one running.
>  - Should it be always?
>  - Should it be under specific case such !smt, cas specific?
> - Should it still chose an idle core first, if not chose waker CPU/Sibling?
> - Should it fallback to waker's LLC vs current LLC. and then choose a CPU
>  in that LLC or choose a recently used cpu, prev_cpu etc? (Current logic)
>

For generic WF_SYNC wakeups, I think the current wake_affine() + SIS flow 
can remain.

Let this patch only handles the narrow reciprocal WF_SYNC handoff on a 
non-SMT system where wake_affine() already selected the waker CPU. In 
that case there is no SMT sibling decision to make, so v4 preserves that 
wake-affine CPU instead of letting SIS move the wakee elsewhere.

I did try the SIS based direction Prateek suggested on the non-SMT Altra 
system. It improved the baseline, but keeping the non-SMT reciprocal 
case in the wake-affine path was still faster. For SMT, I agree the policy 
should be different. The cache local target may be an idle SMT sibling on 
the waker core, not the waker CPU itself, so that belongs in SIS and 
idle core handling.

So I plan to keep v4 limited to the non-SMT reciprocal handoff case and 
leave SMT placement to that separate path, unless folks prefer otherwise.

Thanks,
Shubhang Kaushik