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

Qais Yousef
2026-04-06T00:43:45Z

On 04/03/26 23:32, Peter Zijlstra wrote:
> On Fri, Apr 03, 2026 at 07:19:36PM +0000, Salvatore Dipietro wrote:
> > We are reporting a throughput and latency regression on PostgreSQL
> > pgbench (simple-update) on arm64 caused by commit 7dadeaa6e851
> > ("sched: Further restrict the preemption modes") introduced in
> > v7.0-rc1.
> >
> > The regression manifests as a 0.51x throughput drop on a pgbench
> > simple-update workload with 1024 clients on a 96-vCPU
> > (AWS EC2 m8g.24xlarge) Graviton4 arm64 system. Perf profiling
> > shows 55% of CPU time is consumed spinning in PostgreSQL's
> > userspace spinlock (s_lock()) under PREEMPT_LAZY:
> >
> > |- 56.03% - StartReadBuffer
> > |- 55.93% - GetVictimBuffer
> > |- 55.93% - StrategyGetBuffer
> > |- 55.60% - s_lock <<<< 55% of time
> > | |- 0.39% - el0t_64_irq
> > | |- 0.10% - perform_spin_delay
> > |- 0.08% - LockBufHdr
> > |- 0.07% - hash_search_with_hash_value
> > |- 0.40% - WaitReadBuffers
>
> The fix here is to make PostgreSQL make use of rseq slice extension:

Or perhaps use a longer base_slice_ns in debugfs? I think we end up just short
of 4ms in most systems now. 5 or 6 ms might help re-hide it.

>
> https://lkml.kernel.org/r/20251215155615.870031952@linutronix.de
>
> That should limit the exposure to lock holder preemption (unless
> PostgreSQL is doing seriously egregious things).