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.
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:
- 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:
- 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
Aún no hay comentarios.