An Amazon engineer identified a kernel-specific regression. Linux 7.0, which is expected to be released on April 13th. A change in task scheduler settings resulted in a significant reduction in throughput and responsiveness when running PostgreSQL on ARM64 systems. When using kernel 7.0, performance in the pgbench "simple-update" test dropped almost twofold, from 98565 to 50751.
The slowdown was caused by changing the default scheduler preemption mode from PREEMPT_NONE to PREEMPT_LAZY on architectures that support it. This caused PostgreSQL to spend 55% of its CPU time calling s_lock() in user space. To address this issue, it is proposed to return PREEMPT_NONE to the default and unlink it from the ARCH_NO_PREEMPT setting.
Peter Zijlstra, the author of the changes that caused the regression and the maintainer of the task scheduler and lock-related kernel subsystems, stated that a fix needs to be implemented in the PostgreSQL code. To address the performance degradation, he recommended using the recently added "rseq slice" (Restartable Sequences) extension in the PostgreSQL kernel to limit the likelihood of lock holder eviction.
It's still unclear what decision Linus Torvalds will make, as he adheres to the principle that the kernel should not degrade performance or break user-space compatibility. On the one hand, kernel 7.0 is in the final testing phase before release, and rolling back the scheduler settings could lead to other regressions. On the other hand, users could experience a halving of the performance of one of the most popular databases.
Source: opennet.ru
