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

[partcyborg]

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?

PostgreSQL does not horizontally scale like that, so no you wouldn't get more throughput from a single db. However, you could run 4 different dbs and not experience the same dropoff in scaling

[schmidtbag]

Seems like some applications still have an upper limit to how many threads they can utilize; perhaps 128, when you consider the major dropoff at 384. I suspect that despite what the application sees, the scheduler knows there are more available threads. This causes the threads to jump between core clusters or sockets, which dramatically hurts performance, apparently enough where 48 threads is often faster or close to it. For workloads that use all threads, you wouldn't get this problem because there's no point in swapping threads around. I'm sure if some of these benches prevented their threads from hopping around, the graph would mostly plateau at 192 and 384 threads.

[arcivanov]

Really curious at what's happening at the magic number of "192". Seems to be some monstrous bottleneck somewhere.

[unwind-protect]

Really curious at what's happening at the magic number of "192". Seems to be some monstrous bottleneck somewhere.

That's the number of actual cores. Above that you use more hypderthreading.

Hyperthreading has limited throughput benefit but you still suffer from lock contention, so performance might drop overall.