Re: [PATCH 0/1] sched: Restore PREEMPT_NONE as default

[Andres Freund]

Hi,

On 2026-04-05 10:09:35 -0400, Andres Freund wrote:
> FWIW, from what I can tell, the whole "WHAA, it's a userspace spinlock" part
> has just about nothing to do with the problem.  My understanding is that
> default futexes don't transfer the lock waiter's scheduler slice to the lock
> holder (there's no information about who the lock holder is unless it's a PI
> futex), Postgres' spinlock have randomized exponential backoff and the amount
> of spinning is adjusted over time, so you don't actually end up with spinlock
> waiters preventing the lock owner from getting scheduled to a significant
> degree.

Confirmed, a hack moving this to a futex based lock mirrors has very similar
performance, including somewhat worse performance with PREEMPT_LAZY than
PREEMPT_NONE.  Using futexes has a bit lower throughput but also reduces CPU
usage a bit for the same amount of work, which is about what you'd expect.

Just to re-emphasize: That is just due to using 4kB pages in a huge buffer
pool and would vanish once running for a bit longer or when using a smaller
buffer pool.


I'll look at trying out the rseq slice extension in a bit, it looks like it
nice for performance regardless of using spinlocks.

Greetings,

Andres Freund