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

[Madadi Vineeth Reddy]

Hi Kayra,

On 06/08/26 18:33, Kayra Cizmeci wrote:
> Hi Vineeth,
> 
> Since all the numbers on this thread are from POWER, I ran this on x86 (Zen 3). I ran the test 3 times on both
> baseline and baseline + patch. 
> 

Thank you for running this on x86

> I first got the baseline from 0d83957076 that was like that: 
> 
> =num===cycles===cache-misses= 
> [ 1: 11266587459: 19064897  ]
> [ 2: 11329575367: 18860444  ]
> [ 3: 11283159019: 19121436  ]
> 
> Then, I got the 0d83957076 + this patch:
> 
> =num===cycles===cache-misses=
> [ 1: 11128721747: 19886131  ]
> [ 2: 11163014797: 20019508  ]
> [ 3: 11111832330: 19764849  ]

Can you also provide the benchmark numbers so as to see if this patch helped or not?
I would like to see whether the ping-pong throughput moved in the same direction as cycles.

> 
> I tested them with AMD Ryzen 7 5700X 8 Cores, 16 Threads or by other means SMT2. Busybox, minimal initramfs and 
> perf or to be more specific, this command: perf stat -r 10 -e cycles,cache-misses perf bench sched pipe
> 
> There is a 1.40% decrease of cycles baseline to this patch while there is a 4.60% increase in cache-misses. 
> Both of these values are average values of the decrease and the increase. The values also don't overlap.
> 
> I don't really have explanations for why this values came back like that, 
> I wasn't expecting them to be like this. Especially cache-misses.

It would help if you can get L1, L2, L3 misses split in both cases. May be L1/L2 misses
are more but since they are cheaper than L3, we may be alright or wakeup is cheaper when it
stays within a core, independently of any data-cache effect, in which case
the two counters are measuring unrelated things -- scheduling got cheaper
while the memory access pattern got worse. I do not have evidence for that
yet, which is why I would like the benchmark numbers.

> 
> Tested-by: Kayra Cizmeci <kayracizmeci@xxxxxxxxx>

Will respin another version based on suggestions from Prateek and in_task() gate that Chen Yu
suggested. Let me know if I can carry forward this tag or drop it in v2.

Thanks,
Vineeth

> 
> Thanks,
> Kayra