Re: [PATCH] sched/fair: Let sync wakeups target the waker's core

[Zhan Xusheng <zhanxusheng1024@gmail.com>]

From: Zhan Xusheng <zhanxusheng1024@gmail.com>

On Sat, Aug 01, 2026 at 09:25:32AM +0530, Madadi Vineeth Reddy wrote:
> Pass the waker's CPU down to select_idle_core() in that case and let it
> count as idle. The waker's core then remains an idle-core candidate and
> the wakee is placed on one of its sibling threads.

Nice, and thanks for laying out the other approaches in the changelog.

If I read select_idle_cpu() right, which sibling the wakee actually lands
on depends on the wrap scan order: it iterates
for_each_cpu_wrap(cpu, cpus, target + 1) and select_idle_core() returns the
first fully-idle core it hits.

On POWER SMT8 the SMT siblings are numbered contiguously, so the waker's
sibling sits right at target + 1 and is reached first - exactly the intent.

On layouts where the siblings are not adjacent to the waker - e.g. the
common x86 enumeration where the sibling is at cpu + nr_cores rather than
cpu + 1 - the scan visits other cores first, and if any of them is fully
idle it returns that (cold) core before ever reaching the waker's sibling.
There the cache-sharing win would not materialise; the wakee lands where
plain SIS would have put it. It should not regress, but the benefit looks
like it could be largely specific to contiguously numbered SMT.

Would you be able to share x86 / arm64 SMT2 numbers? That would help show
whether the waker's sibling actually gets picked on those layouts, or
whether the effect is mostly seen on contiguously numbered SMT.

Thanks,
Zhan Xusheng