Linux 6.0 fusiona la corrección de rendimiento de AMD para la antigua solución alternativa «Dummy Wait»

Esta mañana llamé la atención sobre el trabajo en curso relativo a una solución de chipset de 20 años en el kernel de Linux había dañado los sistemas AMD modernos todavía aplicando erróneamente el cambio al hardware moderno. Afortunadamente, Linus Torvalds ha recogido este parche a tiempo para el Linux 6.0 kernel esperado para su debut estable el próximo fin de semana.

Como se mencionó en este artículo anterior, desde 2002, cuando se agregó la compatibilidad con ACPI al kernel, se agregó una operación de «espera ficticia» debido a algunos conjuntos de chips en el momento en que STPCLK# no se afirmó a tiempo a lo largo de la ruta de inactividad en el kernel. La lectura de E/S ficticias retrasa el procesamiento de instrucciones adicionales hasta que la CPU se detiene por completo. Pero un ingeniero de AMD notó recientemente que este comportamiento se aplica en el hardware AMD Zen 3 moderno y descubrió que puede causar problemas de rendimiento para cargas de trabajo que cambian rápidamente entre fases ocupadas e inactivas, especialmente para sistemas con mayor cantidad de núcleos como Ryzen Threadripper y plataformas EPYC.

El muestreo de algunas cargas de trabajo con IBS en el sistema AMD Zen3 muestra que se dedica una cantidad significativa de tiempo a la operación simulada, que se cuenta incorrectamente como una residencia de C-State. Un valor de residencia de C-State grande puede hacer que el gobernador de cpuidle recomiende un C-State más profundo durante las instancias inactivas subsiguientes, lo que desencadena un círculo vicioso que conduce a una degradación del rendimiento en las cargas de trabajo que cambian rápidamente entre las fases ocupada e inactiva.

Una de esas cargas de trabajo es tbench, donde se puede ver una degradación masiva del rendimiento durante algunas ejecuciones.

El ingeniero de AMD, K Prateek Nayak, mostró el impacto significativo en el rendimiento que esta solución alternativa errónea para el hardware moderno puede tener en los sistemas de AMD. Los sistemas Intel, por otro lado, no utilizan esta ruta de código para el hardware moderno y, por lo tanto, no se ven afectados.

Originalmente se sugirió una corrección de AMD, pero luego el ingeniero de Intel, Dave Hansen, la limpió/simplificó. Este parche simplemente no aplica esta solución alternativa de «espera simulada», excepto para los sistemas Intel más antiguos (anteriores a Nehalem), por lo que los sistemas AMD ahora renunciarán a esta operación que puede degradar el rendimiento en los sistemas modernos. Con un impacto principalmente en las cargas de trabajo que a menudo hacen la transición entre estados ocupados e inactivos y más notable para los sistemas de mayor cantidad de núcleos, el rendimiento del servidor AMD EPYC con este parche debería ser bastante bueno, especialmente para las cargas de trabajo del servidor web/base de datos y otros tipos de pruebas rápidas. Mañana lanzaré un conjunto completo de puntos de referencia de alto perfil para evaluar este parche.

El parche se lanzó esta noche como parte de los parches «x86/urgentes» enviados como parte de este tirón delante La versión estable de Linux 6.0 se espera para el 2 de octubre. Es bueno verlo aterrizar rápidamente y estar atento a algunos puntos de referencia.