Messages in this thread | | | Subject | Re: [RFC PATCH] sched/fair: Introduce SIS_PAIR to wakeup task on local idle core first | From | Mike Galbraith <> | Date | Fri, 19 May 2023 13:15:20 +0200 |
| |
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
| |