AWS engineer reports PostgreSQL perf halved by Linux 7.0, fix may not be easy

Post by scottlamb » Tue, Apr 07, 2026, 3:28 PM UTC

menaerus wrote: post #164

db48x wrote: post #160

Earlier quoted context omitted.

No… I’m assuming that they didn’t use the same automation that creates RDS clusters for actual customers. No doubt that automation configures the EC2 nodes sanely, with hugepages turned on. Leaving them turned off in this benchmark could have been accidental, but some accident of that kind was bound to happen as soon as the tests use any kind of setup that is different from what customers actually get.

You're again assuming that having huge pages turned on always brings the net benefit, which it doesn't. I have at least one example where it didn't bring any observable benefit while at the same time it incurred extra code complexity, server administration overhead, and necessitated extra documentation.

Post by silon42 » Wed, Apr 08, 2026, 1:45 PM UTC

jcalvinowens wrote: post #139

silon42 wrote: post #137

Earlier quoted context omitted.

If you are spinning so long that it requires preemption, you're doing something wrong, no?

It doesn't matter, it's a long tail thing: on average user spinlocks can work, and even appear to be beneficial on benchmarks (for many reasons, Andy alludes to some above). But if you have enough users, some of them will experience the apocalyptic long tail, no matter what you do: that's why user spinlocks are unacceptable. RSEQ is the first real answer for this, but it's still not a guarantee: it is not possible to…

Post by scottlamb » Sun, Apr 12, 2026, 11:37 PM UTC

menaerus wrote: post #172

scottlamb wrote: post #171

Earlier quoted context omitted.

FYI: huge pages isn't just a system-wide toggle, but a variety of things you can do: * explicit huge pages * transparent huge pages system-wide default * app-specific or even mapping-specific toggles * various memory allocator settings to raise its effectiveness It would be really surprising to me to see a workload for which it's optimal to not use huge pages anywhere on the system.

It is a system-wide toggle in a sense that it requires you to first enable huge-pages, and then set them up, even if you just want to use explicit huge pages from within your code only (madvise, mmap). I wasn't talking about the THP. When you deploy software all around the globe and not only on your servers that you fully control this becomes problematic. Even in the latter case it is frowned upon by admins/teams if…

Post by scottlamb » Thu, Apr 16, 2026, 1:16 AM UTC

menaerus wrote: post #176

scottlamb wrote: post #175

Earlier quoted context omitted.

> Yes, there are workloads where huge-pages do not bring any measurable benefit I really doubt it, except of course workloads where you just use a trivial amount of memory to begin with. In systems I've seen, anywhere from 5% to 15% of the CPU time is spent waiting for TLB misses. It's obvious then that huge pages can be hugely beneficial if properly used; by definition they hugely relieve TLB pressure. You can of co…

You don't seem to understand the idea that CPU spending time on TLB misses and at the same time seeing no measureable effects in E2E performance because much larger bottleneck is elsewhere can be both valid simultaneously. In database kernels with large and unpredictable workloads, high IO and memory footprint, this is certainly easy to prove.