Hi Jean-Baptiste,
On Fri, 16 May 2025 at 17:05, Jean-Baptiste Roquefere jb.roquefere@ateme.com wrote:
Hello Prateek, long time no see... I've been very busy lately.
Did he try with relax_domain_level=3, i.e. prevent newilde idle
balance between LLC ? I don't see results showing that it's not enough to prevent newly idle migration between LLC
I don't think he did. JB if it isn't too much trouble, could you please try running with "relax_domain_level=3" in kernel cmdline and see if the performance is similar to "relax_domain_level=2".
I just tried relax_domain_level=3 on my payload. As you can see relax_domain_level=3 performances are more or less the same
As there is no difference between level2 and level3, I assume that the problem is not linked to a core to core migration but only the migration between LLC.
As said previously, I don't see an obvious connection between commit 16b0a7a1a0af ("sched/fair: Ensure tasks spreading in LLC during LB") which mainly ensures a better usage of CPUs inside a LLC. Do you have cpufreq and freq scaling enabled ? The only link that I could think of, is that the spread of task inside a llc favors inter LLC newly idle load balance
+--------------------+---------------------+---------------------+ | Kernel | 6.12.17 relax dom 2 | 6.12.17 relax dom 3 | +--------------------+---------------------+---------------------+ | Utilization (%) | 52,01 | 52,15 | | CPU effective freq | 1 294,12 | 1 309,85 | | IPC | 1,42 | 1,40 | | L2 access (pti) | 38,18 | 38,03 | | L2 miss (pti) | 7,78 | 7,90 | | L3 miss (abs) | 33 929 609 924,00 | 33 705 899 797,00 | | Mem (GB/s) | 49,10 | 48,91 | | Context switches | 107 896 729,00 | 106 441 463,00 | | CPU migrations | 16 075 947,00 | 18 129 700,00 | | Real time (s) | 193,39 | 193,41 | +--------------------+---------------------+---------------------+
We got the point that tuning this variable is not a good solution, but for now it's the only one we can apply.
Without this tuning our solution loses real time video processing. With : we keep real time on.
Thanks for your help, I'll stay alert on this thread if someday a better solution can emerge.
Regards,
jb