Linux 7.0 regresja PostgreSQL ARM64

# Regresja w jądrze Linuksa 7.0 podwaja czas w s_lock() w PostgreSQL na ARM64

Deweloper Amazon Salvatore DiPietro podczas testowania PostgreSQL na wersji przedpremierowej jądra Linuksa 7.0 odkrył spadek wydajności na systemach ARM64. Test pgbench w scenariuszu simple-update wykazał obniżenie TPS z 98 565 do 50 751 — prawie dwukrotne. Problem wynika ze zmiany trybu preempcji w planiście zadań: domyślnie z PREEMPT_NONE przełączono na PREEMPT_LAZY dla obsługiwanych architektur.

Ta zmiana spowodowała, że PostgreSQL w przestrzeni użytkownika zużywa 55% czasu CPU na wywołania s_lock(). Jądro 7.0 jest planowane dla Ubuntu 26.04 LTS, premiera oczekiwana w połowie kwietnia 2026 roku.

Szczegóły regresji i analiza

Zmiana w planiście wprowadzona przez Petera Zijlstrę aktywowała PREEMPT_LAZY, powiązaną z ARCH_NO_PREEMPT. Na ARM64 nasila to wywłaszczanie zadań, co jest krytyczne dla wysokoobciążonych systemów zarządzania bazami danych, takich jak PostgreSQL.

Profilowanie wykazało:

• Wzrost czasu w s_lock() do 55% całkowitego czasu CPU.
• Obniżenie przepustowości i responsywności pod obciążeniem pgbench.
• Wpływ wyłącznie na architektury obsługujące tryb LAZY.

Eksperci wskazują, że końcowa faza testów jądra 7.0 ogranicza możliwość cofnięcia zmian bez ryzyka nowych regresji.

Propozycje napraw

DiPietro proponuje przywrócenie PREEMPT_NONE jako domyślnego i odłączenie go od ARCH_NO_PREEMPT. Zijlstra, autor poprawki i opiekun podsystemu planisty, nalega na dopracowanie PostgreSQL:

• Wykorzystanie rozszerzenia rseq slice (Restartable Sequences) z jądra do minimalizacji wywłaszczania posiadaczy blokad.
• Optymalizację obsługi spinlocków w kodzie użytkownika.

Rseq slice umożliwia atomowe sprawdzanie i aktualizację stanu sekwencji, zmniejszając ryzyko przerwania krytycznych sekcji.

Pozycja społeczności i decyzja Linusa

Eksperci OpenNET podkreślają zasadę Linusa Torvaldsa: jądro nie powinno pogarszać wydajności ani naruszać kompatybilności z przestrzenią użytkownika. Konflikt między cofnięciem zmian w jądrze (ryzyko dla premiery) a poprawką w PostgreSQL (wymaga modyfikacji systemu bazodanowego) pozostaje nierozstrzygnięty.

Dla programistów średniego i zaawansowanego poziomu testujących PostgreSQL na ARM64:

• Sprawdzajcie wydajność pgbench na jądrze 7.0-rc.
• Monitorujcie zużycie %CPU w s_lock() za pomocą perf.
• Rozważcie użycie rseq do optymalizacji blokad we własnych projektach.
• Śledźcie LKML w poszukiwaniu poprawek planisty.

Co ważne

• Regresja dwukrotnie obniża TPS w PostgreSQL na ARM64 z powodu PREEMPT_LAZY.
• Zijlstra zaleca rseq slice w przestrzeni użytkownika zamiast cofania zmian w jądrze.
• Ostateczna decyzja należy do Torvaldsa przed premierą Linuksa 7.0 w kwietniu 2026.
• Testujcie na wersjach rc: perf record -e cycles do analizy s_lock().

— Editorial Team