Una solución de conjunto de chips de 20 años ha cobrado su precio en los sistemas AMD Linux recientes

El ingeniero de AMD, K Prateek Nayak, reveló recientemente que una solución de conjunto de chips de casi 20 años en el kernel de Linux que aún se implementa en los sistemas AMD modernos es, en algunos casos, responsable de dañar el rendimiento en las máquinas Zen modernas. Afortunadamente, hay una solución en camino para limitar esta solución a los sistemas más antiguos y, por lo tanto, ayudar con el rendimiento de los sistemas modernos.

la semana pasada fue corrección Se publicó para el código inactivo del procesador ACPI a fin de evitar una solución para los conjuntos de chips heredados en los sistemas AMD Zen modernos. Desde que se agregó la compatibilidad con ACPI al kernel de Linux en 2002, ha habido un «comando de espera ficticio» para manejar algunos chips en los que STPCLK# no se confirma a tiempo. La lectura de E/S fantasma retrasa el procesamiento de instrucciones adicionales hasta que la CPU se apaga por completo. Esto ha sido un problema al menos con algunos sistemas AMD Athlon-era con chips VIA… pero no un problema con chips más nuevos durante las últimas dos décadas más o menos.

El kernel de Linux durante las últimas dos décadas todavía se está implementando innecesariamente para conjuntos de chips más antiguos en los sistemas AMD modernos, lo que a su vez puede comprometer el rendimiento en cargas de trabajo específicas.

Con esta solución aún aplicándose a los sistemas AMD modernos, K Prateek Nayak descubrió:

El muestreo de ciertas cargas de trabajo con IBS en un sistema AMD Zen3 muestra que se dedica una cantidad significativa de tiempo al proceso ficticio, que se calcula incorrectamente como residencia en C-State. Un valor de residencia alto en C-State puede indicarle al gobernador de la CPU que recomiende un estado C más profundo durante los estados inactivos subsiguientes, lo que inicia un círculo vicioso y degrada el rendimiento en las cargas de trabajo que pasan rápidamente de las fases ocupadas a las inactivas.

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

Al menos para Tbench, esta solución incondicional en el kernel de Linux estaba perjudicando el rendimiento de AMD Ryzen/Threadripper/EPYC en cargas de trabajo específicas:

Esta solución alternativa no afectó a los sistemas Intel más nuevos porque las plataformas Intel más nuevas utilizan en su lugar la ruta del código del controlador Intel_idle basada en MWAIT.

La evolución del parche de AMD en este parche Por el ingeniero de Intel Linux Dave Hansen. Este parche para reducir una solución de «espera fantasma» en sistemas heredados ya está en cola en la rama x86/urgente de TIP. Siguiendo la ruta «x86/urgente» y para corregir una solución demasiado entusiasta que no es necesaria en las máquinas modernas, esta semana este parche probablemente se enviará al kernel de Linux 6.0 en lugar de esperar hasta la próxima ventana de combinación (v6.1). .