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

[Shubhang]

Hello Prateek,

On Thu, 30 Jul 2026, K Prateek Nayak wrote:

> Hello Shubhang,
>
> Building on top of Chris' suggestion on v2 for systems with SMT, we can
> push that check further down into select_idle_sibling() and can take a
> call at the point where we know what test_idle_core() returns.
>
> This is what I tried out on top of tip:sched/core:
>
>  (Lightly tested on a SMT-2 system)

I retested both approaches on top of tip:sched/core on the 80-core 
non-SMT Ampere Altra.

  Baseline tip:sched/core, perf bench sched pipe -l 1000000, 20 runs:
    default:       4.063 usec/op mean, 4.100 median
    same-cpu-79:   3.192 usec/op mean, 3.192 median
    two-cpu-78-79: 4.175 usec/op mean, 4.262 median

  With your SIS-based change:
    default:       3.392 mean, 3.332 median
    same-cpu-79:   2.755 mean, 2.754 median
    two-cpu-78-79: 3.311 mean, 3.340 median

  With the narrow non-SMT direct wake-affine return:
    default:       2.886 mean, 2.859 median
    same-cpu-79:   2.737 mean, 2.736 median
    two-cpu-78-79: 2.799 mean, 2.800 median

> +		return select_idle_sibling(p, prev_cpu, new_cpu, sync);
>
> 	return new_cpu;
> }
> ---
>
> I'm currently seeing a ~10% improvement for the workload you mentioned
> (perf bench sched pipe -l 1000000) on average. I haven't tried anything
> else yet but would love to know your thoughts.
>
> I'm using rq->rd->span to know the CPUs covered by the cpuset instead of
> sched_domain_span(sd_llc) in select_idle_smt() to make it work for
> sched_asym_cpucap_active() + sched_smt_active() where some cores may
> have more than one CPUs and the LLC is defined at core boundary.
>
> Basically I wanted to avoid this ugly:
>
>    sd = rcu_dereference_all(per_cpu((sched_asym_cpucap_active()) ? sd_asym : sd_llc, target));
>
>    if (!sd)
>        goto skip;
>
> pattern and rq->rd->span seemed just fine since it doesn't need a null
> check and gives the desired boundary.
>
> Could you please check if the improvements still persist on your system
> with the check pushed down into select_idle_sibling(). Thank you.

SIS direction does improve the baseline here: default perf bench 
sched pipe improves by about 16.5% mean / 18.7% median over 20 runs. But 
on non-SMT Altra system the direct wake-affine return is still about 15% 
faster than the SIS version for the default and two-CPU cases.

I agree that for SMT systems this decision is better handled 
closer to SIS, since SIS can prefer an idle sibling on the waker core 
instead of stacking both tasks on one hardware thread.

On non-SMT systems however, there is no sibling placement decision to 
make. Once the wakeup matches the narrow reciprocal WF_SYNC pattern, 
preserving the wake-affine waker CPU directly thus performs better than 
pushing the decision into SIS in my testing.

Regards,
Shubhang Kaushik