Volver al inicio

Regresión de Linux 7.0 en PostgreSQL ARM64

En Linux 7.0, regresión del scheduler reduce a la mitad el rendimiento de PostgreSQL en ARM64 debido a PREEMPT_LAZY y tiempo aumentado en s_lock(). Amazon sugiere rollback, Zijlstra — rseq en userspace. Solución esperada antes del lanzamiento.

Caída del doble en PostgreSQL en Linux 7.0: problema s_lock
Advertisement 728x90

Regresión en Linux 7.0 duplica el tiempo en s_lock() en PostgreSQL en ARM64

El desarrollador de Amazon Salvatore DiPietro descubrió una caída en el rendimiento en sistemas ARM64 mientras probaba PostgreSQL en la versión prelanzamiento del kernel de Linux 7.0. La prueba pgbench en el escenario simple-update mostró TPS cayendo de 98.565 a 50.751, casi la mitad. El problema se debe a un cambio en el modo de preemption del programador de tareas: el valor predeterminado pasó de PREEMPT_NONE a PREEMPT_LAZY para las arquitecturas compatibles.

Este cambio provocó que PostgreSQL en el espacio de usuario gastara el 55 % del tiempo de CPU en llamadas a s_lock(). El kernel 7.0 está previsto para Ubuntu 26.04 LTS, con lanzamiento esperado a mediados de abril de 2026.

Detalles y análisis de la regresión

El cambio en el programador, realizado por Peter Zijlstra, activó PREEMPT_LAZY, ligado a ARCH_NO_PREEMPT. En ARM64, esto aumenta la preemption de tareas, algo crítico para SGBD de alta carga como PostgreSQL.

Google AdInline article slot

El perfilado mostró:

  • El tiempo en s_lock() se disparó al 55 % del total de CPU.
  • Menor rendimiento y capacidad de respuesta bajo carga de pgbench.
  • Solo afecta a arquitecturas que admiten el modo LAZY.

Los expertos señalan que la fase final de pruebas del kernel 7.0 limita la opción de revertir sin riesgo de nuevas regresiones.

Soluciones propuestas

DiPietro propone revertir al PREEMPT_NONE por defecto y desacoplarlo de ARCH_NO_PREEMPT. Zijlstra, autor del parche y mantenedor del subsistema de programador, insiste en mejorar PostgreSQL:

Google AdInline article slot
  • Usar la extensión rseq del kernel (Restartable Sequences) para minimizar la preemption de titulares de bloqueos.
  • Optimizar el manejo de spinlocks en el código de espacio de usuario.

La extensión rseq permite comprobaciones y actualizaciones atómicas de estados de secuencia, reduciendo el riesgo de interrumpir secciones críticas.

Posición de la comunidad y decisión de Linus

Los expertos de OpenNET destacan el principio de Linus Torvalds: el kernel no debe degradar el rendimiento ni romper la compatibilidad con el espacio de usuario. El enfrentamiento entre una reversión en el kernel (riesgo en el lanzamiento) y una corrección en PostgreSQL (requiere ajustes en el SGBD) sigue sin resolverse.

Para desarrolladores medios/senior que prueban PostgreSQL en ARM64:

Google AdInline article slot
  • Evalúa el rendimiento de pgbench en kernel 7.0-rc.
  • Monitorea el % de CPU en s_lock() con perf.
  • Considera rseq para optimizar bloqueos en tus proyectos.
  • Sigue LKML para parches del programador.

Puntos clave

  • La regresión reduce a la mitad los TPS de PostgreSQL en ARM64 por PREEMPT_LAZY.
  • Zijlstra recomienda rseq en espacio de usuario en lugar de revertir el kernel.
  • Torvalds decidirá antes del lanzamiento de Linux 7.0 en abril de 2026.
  • Prueba versiones rc: perf record -e cycles para análisis de s_lock().

— Editorial Team

Advertisement 728x90

Leer después