Un benchmark de AWS difundido a principios de abril sugirió que el rendimiento de PostgreSQL en Linux 7.0 caía a 0,51 veces frente a la serie 6.x, lo que avivó el debate sobre si conviene aplazar las actualizaciones de kernel. La realidad es más matizada: la regresión es real, pero responde a una configuración concreta —128 GB de memoria compartida con huge_pages=off sobre un m8g.24xlarge de 96 vCPU— y a un cuello de botella preexistente que la nueva política de preempción del kernel hace visible.
Linux 7.0 eliminó el modo PREEMPT_NONE en arm64, x86, powerpc, riscv, s390 y loongarch; los sistemas pasan a usar PREEMPT_FULL o, por defecto en la mayoría de distribuciones, PREEMPT_LAZY. Esto último no causa el problema, pero amplifica uno previo: el spinlock buffer_strategy_lock dentro de StrategyGetBuffer. En el test, más del 55 % del tiempo de CPU se consume en ese único spinlock, porque un backend puede sufrir un page fault menor mientras lo retiene, y la sección crítica se alarga lo suficiente para que la preempción diferida expulse al portador y haga girar a los demás.
La solución no está en revertir el kernel, sino en activar huge_pages=on (o THP cuando se comporte correctamente). Con páginas enormes, los page faults en el primer acceso pasan de unos 31 millones a unos 61.000 o 120, y la presión sobre la TLB cae entre cuatro y seis órdenes de magnitud. Andres Freund confirmó que, con huge pages habilitadas, la regresión desaparece sobre el mismo hardware.