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
+--------------------+---------------------+---------------------+ | 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