Linux 5.18 Scheduler Change To Further Boost AMD EPYC Performance For Some Workloads

[phoronix]

Phoronix: Linux 5.18 Scheduler Change To Further Boost AMD EPYC Performance For Some Workloads

While AMD EPYC processors already deliver great performance under Linux, with the Linux 5.18 kernel this spring is a scheduler improvement that can provide measurable speed-ups for various workloads on processors where there are multiple last level caches (LLCs) per node, such as with the case of EPYC...

https://www.phoronix.com/scan.php?page=news_item&px=AMD-Linux-5.18-Sched-Zen-LLC

[andrei_me]

Lol wat, almost a gen perf increase with code optimization

[Eirikr1848]

Probably a dumb question: would this also positively impact older Opteron CPUs?

[Spacefish]

Probably a dumb question: would this also positively impact older Opteron CPUs?

Probably not, as the cache design is different.

[lejeczek]

Nice, I hope Michael can do some performance comparison tests rather soon. Many thanks, L.

[paulocoghi]

We use Epyc CPUs on our newest dedicated servers, and the performance is already astonishing. With this optimization, as stated by Andrei, we will receive almost a generation of performance uplift. I couldn't be happier.

[coder]

This reminds me of a malloc() "optimization" I saw that I think is counter-productive for some workloads on NUMA systems, the downside of which is partially addressed by this patch.

https://www.phoronix.com/scan.php?pa...c-thread-cache

What that 2017 patch should do is return memory to the heap of the thread that allocated it -- not the heap of the thread freeing it. That way, if the allocating thread is in a different NUMA domain than the freeing thread, the memory goes back to the cache of its local NUMA domain. I know it would (sometimes) require synchronization that the 2017 patch doesn't, but at least you wouldn't have threads ending up heavily using non-local memory!