Messages in this thread |  | | Date | Fri, 3 Apr 2026 23:32:07 +0200 | | From | Peter Zijlstra <> | | Subject | Re: [PATCH 0/1] sched: Restore PREEMPT_NONE as default |
| |
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:
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).
|  |