You must log in or # to comment.
Wouldn’t it make sense to merge in rseq support well in advance of removing PREEMPT_NONE, not do both at the same time?
But that hurts the ego of the kernel developer because they have to wait for the next release.
sounds like rseq has been around since 2018 https://www.phoronix.com/news/Restartable-Sequences-Speed
I think it’s a bit weird that postgres hasn’t done any testing on the new kernel. That’s something I would kinda expect from a major database. The fact this was only found in production is a bit … weird.
Why would they? The current stable kernel release is still v6.19
Because that’s what you do with important software? You don’t want to stack up potential issues until the final release for the public.
I’ll be curious to see benchmarks of PREEMPT_NONE vs rseq once PostgreSQL patches this
Which is expected to be faster in the end?
This has been known for awhile, and this was already accepted to be an issue with PH memory handling. Not weird, rare or otherwise, it will get fixed.
Maybe Linux is considering prioritizing consumer hardware (safety, less room for human error)? Android is already a thing, so maybe there is pressure for prioritizing consumer hardware?
