La solución de Linux de 20 años sigue ralentizando los sistemas AMD


Agrandar / Un chip de servidor Epyc de segunda generación de AMD, uno que puede haber estado ejecutando código Linux de la era 2002 que lo ralentiza.

imágenes falsas

AMD ha recorrido un largo camino desde 2002, pero el kernel de Linux todavía trata a los Threadrippers modernos como sistemas de la era Athlon, al menos en un aspecto que puede provocar retrasos.

El ingeniero de AMD, Prateek Nayak, presentó recientemente un parche para los controladores inactivos del procesador de Linux que «saltaría la espera ficticia de los procesadores basados ​​en la microarquitectura Zen». Cuando se agregó soporte ACPI al kernel de Linux en 2002, escrito por Andy Grover, comprometido por Linus Torvalds, incluía una «operación de espera ficticia». Básicamente, el sistema lee datos sin otro propósito que retrasar la siguiente instrucción hasta que la CPU pueda detenerse por completo con el comando STPCLK#. Esto permitió cierto ahorro de energía y compatibilidad durante los primeros días de la implementación de ACPI cuando algunos conjuntos de chips no pasaban a un estado inactivo cuando uno lo esperaba.

Pero los chips AMD basados ​​en Zen de hoy en día no necesitan esta solución y, como escribe Nayak, los está perjudicando, al menos en cargas de trabajo específicas en Linux. Las pruebas con cargas de trabajo de muestreo basado en instrucciones (IBS) muestran que «se gasta una cantidad significativa de tiempo en la operación ficticia, que se contabiliza incorrectamente como residencia de C-State». La CPU, al ver todo este trabajo ficticio de bajo esfuerzo, puede pasar a un estado C más profundo y lento, lo que luego hace que la CPU tarde más en «despertar», especialmente en trabajos que requieren muchos cambios entre estados ocupados e inactivos.

Nayak ejecutó pruebas en tbench en un sistema Zen3 de dos sockets contra el kernel de Linux de referencia, un kernel con el estado C2 completamente deshabilitado y un kernel con la operación de espera ficticia parcheada. Su versión parcheada experimentó un aumento del 1390 por ciento en el rendimiento mínimo de MB/s y un aumento del 51 por ciento en la media de MB/s con respecto al kernel de referencia, a menudo solo un poco por detrás de tener C2 deshabilitado por completo.

Los sistemas Intel han evitado la maldición heredada de AMD, ya que utilizan un sistema basado en MWAIT durante al menos una década, según el blog de Phoronix. Eso condujo a un parche urgente enviado por Dave Hansen de Intel. Su solución fue limitar la «espera ficticia» a los sistemas Intel, donde no afectaría a los «sistemas Intel remotamente modernos», y agregar comentarios a los controladores inactivos del kernel que explican lo que está sucediendo, y alentar a los lectores a «considerar mover su sistema a un mecanismo inactivo más moderno».

Si se envía un parche urgente que elimina o limita la «espera ficticia» esta semana, es probable que se produzca el kernel de Linux 6.0, que Torvalds espera enviar la próxima semana.



Source link-49