Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [RFC PATCH] sched/fair: Introduce SIS_PAIR to wakeup task on local idle core first | From | Mike Galbraith <> | Date | Tue, 16 May 2023 13:51:26 +0200 |
| |
On Tue, 2023-05-16 at 16:41 +0800, Chen Yu wrote: > > > IMO this issue could be generic, the cost of C2C is O(sqrt (n)), in theory on > a system with a large number of LLC and with SMT enabled, the issue is easy to > be detected. > > As an example, I did not choose a super big system, > but a desktop i9-10980XE, launches 2 pairs of ping-ping tasks. > > Each pair of tasks are bound to 1 dedicated core: > ./context_switch1_processes -s 30 -t 2 > average:956883 > > No CPU affinity for the tasks: > ./context_switch1_processes -s 30 -t 2 -n > average:849209 > > We can see that, waking up the wakee on local core brings benefits on this platform.
Sure, tiny ping-pong balls fly really fast in a shared L2 siblings. The players being truly synchronous, there's not a whole lot of room for resource competition, and they do about as close to nothing but schedule as you can get.
That's not a workload, much less one worthy of special consideration. It is a useful tool though, exposed a big socket issue, good job tool. Changing task placement strategy in response to that issue makes zero sense to me. There are many ways to schedule and wake other tasks at high frequency, all use the same paths. Reduce the pain that big box sees when playing high speed ping-pong, and real workloads will profit in boxen large and small. More in large than small, but nobody loses, everybody wins.
-Mike >
| ![\](/images/icornerr.gif) |