Re: [PATCH v4] sched/fair: Preserve wake-affine CPU for non-SMT reciprocal sync wakeups

Hi Shrikanth,

On Tue, 4 Aug 2026, Shrikanth Hegde wrote:

> Hi Shubhang.
>
> Please give time for discussion/reply for the people looking at
> your patches. Even before I could respond to your v3, you have sent v4.
> And your v4 doesn't addresses the concerns raised in v3.
>

Yes, v4 only narrowed the implementation. It moved the check after 
wake_affine(), only preserves the waker CPU when wake_affine() already 
selected it and keeps SMT out of the direct return path.

But it does not fully address your broader policy/documentation 
concern around what WF_SYNC should mean. I will hold off on another 
revision until there is more agreement there.

> On 8/4/26 7:15 AM, Shubhang Kaushik (Ampere) wrote:
>> Handle only this narrow reciprocal case on non-SMT systems. Once the
>> wake-affine path has selected or kept the waker CPU, preserve that target
>> when the waker rq has no other runnable fair task. Return the waker CPU
>> before select_idle_sibling() so the idle CPU search does not move this
>> handoff away from the wake-affine target.
>> 
>
> Why on non-SMT? Why the same problem cannot happen in SMT systems?
>

On SMT, returning the exact waker CPU is not obviously the right policy. 
An idle SMT sibling on the waker's core may be a better target, or the 
existing SIS choice may still be better depending on the workload and 
topology. Returning the waker CPU early would hide that SMT-specific 
choice from SIS. That was also the concern raised earlier by Vineeth, 
and is why I kept SMT out of this patch.

I did try the SIS-based direction Prateek suggested on the non-SMT Altra 
system. It improved the baseline, but it was still slower than preserving 
the wake-affine CPU directly for the non-SMT reciprocal case.

So my intent with v4 was to keep only that narrower non-SMT case here, 
while seperating the SMT, core sibling question to the separate SIS side 
discussion.

>> ---
>> Tested on 80-core non-SMT Ampere Altra, tip:sched/core baseline.
>
> Where is your LLC? Does it has multiple cores and currently
> you end up choosing an idle core?
> Your numbers below pretty much tell the same story.
>

The v4 numbers were collected with SLC-as-L3 disabled. On Ampere Altra
system, sched_verbose reports:

   domain0: MC,  SD_SHARE_LLC
   domain1: PKG, SD_SHARE_LLC

So, from the scheduler's view, there is still a multi-CPU SD_SHARE_LLC
domain in this configuration. In the baseline, wake_affine() can select
the current waker CPU for the sync handoff, but that target still goes
through select_idle_sibling(). SIS can then move the wakee to another
idle CPU in that domain.

>> 
>> perf bench sched pipe -l 1000000, 20 runs:
>
> IIUC, sched pipe doesn't do any work apart from ping-pong.
>

Yes, agreed. sched pipe mostly exposes handoff cost. I am not trying 
to use it to define generic WF_SYNC behavior.

>> default:
>>    3.985 -> 3.187 usec/op mean,   about 20.0% improvement
>>    4.026 -> 3.181 usec/op median, about 21.0% improvement
>> 
>> taskset -c 78,79:
>>    3.851 -> 3.144 usec/op mean,   about 18.4% improvement
>>    3.804 -> 3.140 usec/op median, about 17.4% improvement
>> 
>> taskset -c 79:
>>    3.055 -> 3.113 usec/op mean,   about 1.9% slower
>>    3.045 -> 3.109 usec/op median, about 2.1% slower
>> 
>
> Which means you get the best result when it runs on same CPU.
> The rest of the changes likely enforce that behavior. Then same issue is
> prevalent in SMT world too.
>

Yes, same locality issue can show up on SMT too. The distinction 
is the target. For non-SMT, the local target can be the waker CPU. For 
SMT, the target may need to be the waker's core, an idle SMT sibling, or 
the normal SIS result. That needs the SMT topology to remain visible.

>> Hackbench process/thread pipe cases with 1/2/4/8 groups were within
>> noise, with mean deltas from -1.8% to +3.7% over 10 runs.
>> 
>> Schbench normal mode at 8/40/80/240 workers and schbench pipe mode at
>> 1/2/4/8 workers showed no material regression.
>> 
>> Baseline: tip/sched/core at 5186ef36909c
>
> As I said in v3, before we add bells/whistles to sync path, i want
> to know what is expected of sync behavior today.
> And that should be documented in Documentation/scheduler/
>

I agree. Currently WF_SYNC is a hint, not a strict placement rule.
The fair wakeup path may use WF_SYNC in wake_affine(), but wake_wide(), 
topology, affinity, capacity, idle state and load can still affect where 
the wakee actually runs.

Prateek's data also shows why this is tricky. WF_SYNC can help a strict 
1:1 pipe handoff, but it can hurt other pipe messaging patterns. So I 
can see that documenting the current behavior first is useful, especially 
because the waitqueue comment reads stronger than what the wakeup path 
actually guarantees today.

I can help with Documentation/scheduler/ update describing the current 
WF_SYNC behavior and the wakeup path before sending another version 
of this optimization.

> Be it,
> - current way of hint only and scheduler can still choose an idle core/idle 
> cpu etc.
> - Should it be enforcing it to waker cpu if waker cpu has only one task.
> - Whatever the policy maybe.
>
> Current api usage is tricky to use and effect is visible in real life 
> workloads.
> The case I mentioned in v3 of networking code using sync api leads to strange
> results due to sync mechanism.
> - It depends whether waker/wakee are running on same node.
> - Result of wake_wide.
> In other end, user sees inconsistent latency/throughput.
>
> We can keep on adding minor changes to sync api path,
> but one benchmark will benefit and one will suffer.
> Having the behavior documented is a good start.
>
> Peter, Ingo, Vincent, Mel, Prateek,
> What do you guys think?
>

Please do let me know if you have any other suggestions in the meantime.

Regards,
Shubhang Kaushik