Una solución de conjunto de chips de 20 años ha dañado los sistemas AMD Linux modernos

AMD -- El ingeniero de AMD, K Prateek Nayak, descubrió recientemente que una solución alternativa de chipset en el kernel de Linux de aproximadamente 20 años de antigüedad, que aún se aplica a los sistemas AMD modernos, es responsable en algunos casos de la degradación del rendimiento en el hardware Zen moderno. Afortunadamente, un parche está en camino para limitar esta solución a los sistemas más antiguos y, a su vez, mejorar el rendimiento en los sistemas modernos.

La semana pasada se lanzó una solución para el código inactivo del procesador ACPI para evitar una solución alternativa del conjunto de chips antiguo en los sistemas AMD Zen modernos. Desde que se agregó la compatibilidad con ACPI al kernel de Linux en 2002, ha habido una "operación de espera ficticia" para procesar algunos conjuntos de chips en los que STPCLK# no se afirma a tiempo. La lectura de E/S ficticias retrasa el procesamiento de instrucciones adicionales hasta que la CPU se detiene por completo. Este fue un problema con al menos algunos sistemas AMD Athlon-era con un conjunto de chips VIA... Pero no un problema con los nuevos conjuntos de chips de las últimas dos décadas más o menos.

Una solución del kernel de Linux para las últimas dos décadas prevista para ahora - Los conjuntos de chips antiguos aún se aplican innecesariamente a los sistemas AMD modernos, lo que puede afectar negativamente el rendimiento de algunas cargas de trabajo.

Con esta solución todavía aplicada incluso a los sistemas AMD modernos, K Prateek Nayak descubrió:

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 ficticia, que se cuenta incorrectamente como residencia del estado C. Un valor alto de residencia de C-State puede hacer que el gobernador de cpuidle recomiende un C-State más profundo en instancias inactivas subsiguientes, lo que desencadena un círculo vicioso que conduce a una degradación del rendimiento en cargas de trabajo que cambian rápidamente entre fases ocupadas e inactivas.

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

Al menos para Tbench, esta solución dura de larga data en el kernel de Linux ha afectado el rendimiento de AMD Ryzen/Threadripper/EPYC en algunas cargas de trabajo:

Esta solución alternativa no afectó a los sistemas Intel modernos, ya que estas plataformas Intel más nuevas utilizan en su lugar la ruta del código del controlador intel_idle basada en MWAIT.

El parche de AMD se convirtió en este parche del ingeniero de Intel Linux Dave Hansen. Esta solución para limitar la solución alternativa de "espera ficticia" a sistemas más antiguos 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 el hardware moderno, es probable que este parche se envíe nuevamente esta semana para el kernel de Linux 6.0 en lugar de tener que esperar al próximo (v6.1 ) fusionar ventana.

Una solución de conjunto de chips de 20 años ha dañado los sistemas AMD Linux modernos
AMD -- El ingeniero de AMD, K Prateek Nayak, descubrió recientemente que una solución alternativa de chipset en el kernel de Linux de aproximadamente 20 años de antigüedad, que aún se aplica a los sistemas AMD modernos, es responsable en algunos casos de la degradación del rendimiento en el hardware Zen moderno. Afortunadamente, un parche está en camino para limitar esta solución a los sistemas más antiguos y, a su vez, mejorar el rendimiento en los sistemas modernos.

La semana pasada se lanzó una solución para el código inactivo del procesador ACPI para evitar una solución alternativa del conjunto de chips antiguo en los sistemas AMD Zen modernos. Desde que se agregó la compatibilidad con ACPI al kernel de Linux en 2002, ha habido una "operación de espera ficticia" para procesar algunos conjuntos de chips en los que STPCLK# no se afirma a tiempo. La lectura de E/S ficticias retrasa el procesamiento de instrucciones adicionales hasta que la CPU se detiene por completo. Este fue un problema con al menos algunos sistemas AMD Athlon-era con un conjunto de chips VIA... Pero no un problema con los nuevos conjuntos de chips de las últimas dos décadas más o menos.

Una solución del kernel de Linux para las últimas dos décadas prevista para ahora - Los conjuntos de chips antiguos aún se aplican innecesariamente a los sistemas AMD modernos, lo que puede afectar negativamente el rendimiento de algunas cargas de trabajo.

Con esta solución todavía aplicada incluso a los sistemas AMD modernos, K Prateek Nayak descubrió:

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 ficticia, que se cuenta incorrectamente como residencia del estado C. Un valor alto de residencia de C-State puede hacer que el gobernador de cpuidle recomiende un C-State más profundo en instancias inactivas subsiguientes, lo que desencadena un círculo vicioso que conduce a una degradación del rendimiento en cargas de trabajo que cambian rápidamente entre fases ocupadas e inactivas.

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

Al menos para Tbench, esta solución dura de larga data en el kernel de Linux ha afectado el rendimiento de AMD Ryzen/Threadripper/EPYC en algunas cargas de trabajo:

Esta solución alternativa no afectó a los sistemas Intel modernos, ya que estas plataformas Intel más nuevas utilizan en su lugar la ruta del código del controlador intel_idle basada en MWAIT.

El parche de AMD se convirtió en este parche del ingeniero de Intel Linux Dave Hansen. Esta solución para limitar la solución alternativa de "espera ficticia" a sistemas más antiguos 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 el hardware moderno, es probable que este parche se envíe nuevamente esta semana para el kernel de Linux 6.0 en lugar de tener que esperar al próximo (v6.1 ) fusionar ventana.

What's Your Reaction?

like

dislike

love

funny

angry

sad

wow