Intel Linux Optimizations Help AMD EPYC "Genoa" Improve Scaling To 384 Threads

[phoronix]

Phoronix: Intel Linux Optimizations Help AMD EPYC "Genoa" Improve Scaling To 384 Threads

Last month I wrote about Intel's Linux kernel engineering improvements to help enhance CPU scaling across various workloads by addressing low-level bottlenecks within the kernel. It's an area we'll likely see Intel continue to invest in as Sierra Forest comes next year with 144 E cores per socket. Already with the Linux kernel patches Intel is carrying at the moment via their in-house distribution, there are some significant benefits for Xeon Scalable Sapphire Rapids. I was curious to see how this Intel-focused work impacted AMD EPYC servers and thus in today's article is a similar analysis using two AMD EPYC 9654 "Genoa" flagship processors while evaluating Intel's Linux kernel optimizations.

https://www.phoronix.com/review/amd-epyc-scaling-384

[tildearrow]

Typo:

this allows seeing in turn how Intel's optimzized kernel

[Michael]

Typo:

Fixed, thanks

[unwind-protect]

I would have loved it if you could have thrown FreeBSD into this test.

[HEL88]

THX Intel.

[Michael]

I would have loved it if you could have thrown FreeBSD into this test.

I don't recall offhand if FreeBSD even is running right now on Genoa + Titanite but was already taxing enough to run these tests on just the 3 distros... Due to the number of combinations (especially low thread counts) was very time consuming that I am not even sure yet if I will break even on these tests for what I did run.

[NateHubbard]

If we're going to put "Genoa" in quotes, maybe we can do the same with Intel.
Xeon "Scalable" Sapphire Rapids
Xeon Scalable Sapphire "Rapids"

[NeoMorpheus]

Intel Linux Optimizations Help AMD EPYC "Genoa" Improve Scaling To 384 Threads

intel devs: sorry for the bug, it will be fixed ASAP.

[NeoMorpheus]

I don't recall offhand if FreeBSD even is running right now on Genoa + Titanite but was already taxing enough to run these tests on just the 3 distros... Due to the number of combinations (especially low thread counts) was very time consuming that I am not even sure yet if I will break even on these tests for what I did run.

Thanks for all the amazing work that you do Michael!

[AmericanLocomotive]

Here's a question for those more knowledgeable:

Would you run into these same scaling issues with a bare-metal hypervisor splitting the system into 2, 4 (or more) VMs? Some of the benchmarks level off, or even fall flat on their face after a certain thread count. For example, would you get more throughput on the PostgreSQL 15 benchmark running 4x VMs with 96 vCPUs each?