PREEMPT_NONE Is Dead; Your Postgres Probably Doesn’t Care
29 points by kngl
29 points by kngl
I'm still not convinced you ever really want to use spinlocks in userland.
They are a serialization technique that only the kernel has the right vantage point to use correctly, in userland you are better off informing the kernel of your intentions (whether with rseq, or locks if rseq is unavailable) so that it can make effective scheduling decisions.
I completely agree!
I recognize that they're typically used in userland for latency-sensitive situations, but really their use should be considered a smell requiring a better design. I mean, even being able to configure PREEMPT_NONE is a luxury that not all kernels offer; forget designing cross-platform software around it!
There are use-cases for them, but you have to have deep knowledge of how many threads you are running, core-pinning and knowledge of how many cores are on the machine and the expected wait times on the lock. In cases where you can guarantee that return times are always below some bound a userland spinlock can be vital for latency. At least that has been my current experience.
(whether with rseq, or locks if rseq is unavailable) so that it can make effective scheduling decisions.
but what when your workload forbids system calls altogether due to the need of working soft- or hard- real-time ? Linux supports these use-cases
Spinlocks are not realtime safe either - what happens when there's contention and your realtime thread cannot take the lock?
For sharing complex data structures with a realtime thread you probably want something more like RCU with atomics.
I’d heard the 50% performance drop figure, so I was curious what the penalty for not using huge pages might be—it sounded like it was probably more severe.
From Andres Freund (who investigated and initially failed to reproduce the performance drop, because he had “reflexively used huge_pages=on - as that is the only sane thing to do with 10s to 100s of GB of shared memory”):
Note that the performance effect of not using huge pages is terrible regardless the spinlock. PG 19 does have the spinlock in this path anymore, but not using huge pages is still utterly terrible (like 1/3 of the throughput).
What about other workloads that really want spinlocks ? c.f. https://timur.audio/using-locks-in-real-time-audio-processing-safely ; do they just have to accept the regression ?
Apparently the kernel people have extended the rseq facilities with a "please don't preempt" me bit that gives you something similar to the old behavior, though it is not well documented and might not be enabled in the kernel...
This is a subject I find interesting and would want to read about, but within a few paragraphs I can tell it was written by Claude. And the website seems to be a content farm for a Postgres consultant. The linked blog post is https://mydbanotebook.org/posts/postgres-performance-regression-are-we-there-yet/ and seems more human to me, and it also seems likely that thebuild.com took that post, fed it through an LLM and produced this re-hash.