An engineer from Amazon has identified a regression specific to Linux kernel 7.0, whose release is expected on April 13. Modifying the task scheduler settings has led to a significant decrease in throughput and responsiveness of the PostgreSQL database on ARM64 architecture systems. When using kernel 7.0, performance metrics in the pgbench 'simple-update' test dropped almost by half—from 98,565 to 50,751.
The slowdown is caused by changing the preemption mode in the default scheduler from PREEMPT_NONE to PREEMPT_LAZY on architectures that support such a mode, resulting in PostgreSQL in user space spending 55% of CPU time on calls to s_lock(). To resolve this issue, it has been proposed to revert the default setting back to PREEMPT_NONE and remove its binding to the ARCH_NO_PREEMPT setting.
Peter Zijlstra, the author of the changes that caused the regression and the maintainer of the scheduler and related locking subsystems of the kernel, stated that the fix needs to be made in the PostgreSQL code. To mitigate the performance drop, he suggested using the newly added kernel extension 'rseq slice' (Restartable Sequences) in PostgreSQL to reduce the likelihood of preemption for lock holders.
It is still unclear what solution Linus Torvalds will choose, as he adheres to the principle that the kernel should not degrade performance and break compatibility with user space. On one hand, kernel 7.0 is in the final testing stage before release, and rolling back scheduler settings could lead to other regressions; on the other hand, users may face a twofold decrease in performance of one of the most popular databases.
Source: opennet.ru
