A principios de este mes noté un cambio en el programador de Linux en cola en sched/core antes del ciclo de Linux 5.18 que es Se espera que ayude a los procesadores AMD EPYC y otros procesadores Zen seleccionados en varias cargas de trabajo. El cambio ha estado en proceso durante varios meses y se trata de ajustar el desequilibrio NUMA permitido al abarcar varias LLC. Ahora he llevado a cabo algunos de mis propios puntos de referencia en el hardware EPYC y, de hecho, estoy aumentando aún más el rendimiento del kernel de Linux.
El parche habla de buenas ganancias de rendimiento… Ahora probando de mi parte.
Este cambio en cola en”sched/core”antes de la ventana de combinación de Linux 5.18 del próximo mes no es un cambio específico de AMD, sino uno que beneficia a los procesadores Zen debido a su diseño de caché. Mel Gorman, autor del parche, explicó:”[Un cambio en el programador del kernel de 2020] permitió un desequilibrio entre los nodos NUMA, de modo que el balanceador de carga no separaría las tareas de comunicación. Esto funciona bien cuando hay una relación 1: 1 entre LLC y el nodo, pero puede ser subóptimo para múltiples LLC si las tareas independientes usan prematuramente CPU que comparten caché Zen* tiene múltiples LLC por nodo con canales de memoria local y debido al desequilibrio permitido, es mucho más difícil ajustar algunas cargas de trabajo para que se ejecuten de manera óptima de lo que es en hardware que tiene 1 LLC por nodo. Este parche permite que exista un desequilibrio hasta el punto en que las LLC deben equilibrarse entre nodos”.
Puede confirmar una gran mejora del rendimiento en la serie EPYC 7003 en una variedad de cargas de trabajo con los últimos cambios en la programación/núcleo de TIP.
Los propios puntos de referencia de Mel cuando trabajaba en este parche vieron una mejora de hasta un 272 % para el punto de referencia de la memoria Stream y también otras ganancias considerables como un 10 % más de rendimiento en Coremark y un máximo un máximo de hasta un 17 %, el rendimiento de SPECjbb Java aumentó hasta un 18 %, el punto de referencia vergonzosamente paralelo de NPB fue alrededor de un 17 % más rápido y otras victorias notables. Dados los muy prometedores resultados informados, he estado realizando algunas de mis propias pruebas localmente y los números que estoy viendo son igualmente emocionantes, ¡especialmente para este cambio en el programador del kernel de Linux que solo tiene alrededor de 50 líneas de código nuevo!
En primer lugar, se muestran algunos puntos de referencia ejecutados con un servidor AMD EPYC 75F3 2P construido alrededor de una placa base ASRockRack ROME2D16-2T y con Ubuntu 21.10. El rendimiento se comparó entre Linux 5.17 Git y luego sched/core Git con el parche”sched/fair: Ajustar el desequilibrio NUMA permitido cuando SD_NUMA abarca varias LLC”en cuestión. Se usó el mismo kernel Kconfig entre ambos kernels.