Linux eliminó un workaround inactivo de 2002 y el rendimiento de AMD Zen aumentó hasta 14 veces

Cuando se añadió compatibilidad con ACPI al kernel de Linux en 2002 —escrito por Andy Grover, confirmado por Linus Torvalds—, se incluyó una «operación de espera ficticia»: el sistema leía datos sin otro propósito que retrasar la siguiente instrucción hasta que la CPU pudiera detenerse por completo con el comando STPCLK#. Eso aportaba ahorro de energía y compatibilidad en los primeros tiempos, cuando algunos chipsets se negaban a entrar en estados de inactividad como se esperaba.

Veinte años después, el ingeniero de AMD Prateek Nayak envió un parche del kernel para «omitir la espera ficticia en procesadores basados en la microarquitectura Zen». Los chips Zen modernos no necesitan ese empujón, y las pruebas con muestreo basado en instrucciones mostraron que la operación ficticia seguía consumiendo un tiempo significativo que el kernel contabilizaba incorrectamente como residencia en estado C. Al ver todo ese trabajo de bajo esfuerzo, la CPU se forzaba a entrar en estados C más profundos y lentos, y luego tardaba más en despertar, perjudicando a las tareas que alternan constantemente entre ocupado e inactivo.

Las mediciones fueron drásticas: en ejecuciones de tbench en un sistema Zen3 de doble socket, el kernel parcheado ofreció un aumento del 1.390 % en el rendimiento mínimo en MB/s y un aumento del 51 % en el rendimiento medio en MB/s respecto al kernel de referencia, acercándose al resultado de desactivar por completo el estado de reposo C2.

Los sistemas Intel habían esquivado esa maldición heredada durante una década gracias a un mecanismo de inactividad basado en MWAIT, y Dave Hansen, de Intel, envió un parche urgente que limitaba la espera ficticia a los sistemas Intel —donde no afectaría a máquinas «remotamente modernas»—, además de comentarios que instaban a los lectores a pasar a mecanismos de inactividad más modernos. Enviado a tiempo, la corrección podría haber llegado al kernel Linux 6.0 que se publicaría la semana siguiente.

Una lectura sin efecto de 2002 era malinterpretada por la gestión de energía como prueba de carga ligera, lo que empujaba a los núcleos Zen a un sueño profundo; eliminarla elevó el rendimiento mínimo un 1.390 %.

El diagnóstico es la genialidad: el muestreo basado en instrucciones reveló que el tiempo desperdiciado se estaba etiquetando erróneamente como sueño saludable, convirtiendo un error de contabilidad de la gestión de energía en un precipicio de rendimiento visible.

La corrección cuesta una rama —omitir la espera ficticia en Zen— y, sin embargo, recupera catorce veces el rendimiento mínimo, una proporción rara vez alcanzable con cualquier optimización de trabajo real.

Es un espécimen vivo de deuda técnica: el código añadido para chipsets de 2002 sobrevivió dos décadas y varias generaciones de CPU porque nada falló nunca, solo se volvió más lento.

Las capas de compatibilidad sobreviven al hardware al que sirven: a menos que alguien las audite de nuevo frente al silicio nuevo, una operación sin efecto de hace 20 años puede convertirse en un impuesto invisible que parece un problema del chip.

El parche Zen de Nayak y el seguimiento urgente de Hansen que limitaba la espera ficticia a los sistemas Intel se enviaron a finales de septiembre de 2022, a tiempo para ser considerados en el kernel Linux 6.0 que Torvalds esperaba publicar la semana siguiente. El parche de Intel también añadió comentarios que fomentaban la migración a mecanismos de inactividad modernos. Ars Technica informó que no hubo problemas residuales para los sistemas AMD una vez aplicado el parche.