Re: [RFC PATCH] sched/fair: Introduce SIS_PAIR to wakeup task on local idle core first

[Mike Galbraith]

On Thu, 2023-05-18 at 11:41 +0800, Chen Yu wrote:
> On 2023-05-17 at 21:52:21 +0200, Mike Galbraith wrote:
> >
> > That said, I don't like the waker/wakee have met heuristic much either,
> > because tasks waking one another before can just as well mean they met
> > at a sleeping lock, it does not necessarily imply latency bound IPC.
> >
> Yes, for a sleeping lock case, it does not matter whether it is woken up
> on sibling idle, or an idle CPU on another half-busy core. But for the
> pair sharing data, it could bring benefit.

That reply keeps bouncing about in my head, annoying me enough that I'm
going to reply to it so I can finally stop thinking about pipe ping-
pong and the risks of big socket only issue mitigation patches.

The object that inspired SIS_CURRENT, which then morphed into SIS_PAIR
is in effect a mutex.  The numbers derived from operation of that mutex
are not really relevant to IPC or context switches for that matter
(says me;), they're all about memory access cost deltas.

	-Mike