Corrige la degradación severa en el rendimiento de Linux observada por Torvalds

Antes de que Linus Torvalds perdiera Internet y energía debido a una tormenta de nieve que afectó la ventana de integración de Linux 6.8, su fin de semana ya estaba en mal estado debido a que enfrentaba una caída de rendimiento con el nuevo código de Linux 6.8 que estaba causando que su kernel de Linux se compilara. Es el doble de lo que era con los núcleos anteriores. Un ingeniero de AMD Linux pudo reproducir la regresión y, con los desarrolladores principales, ahora hay una solución confirmada a este problema en el último código de programación.

En la discusión sobre la importante regresión en el rendimiento reportada por Linus Torvalds que surgió de los cambios en el programador en Linux 6.8, para el compromiso dividido, no quedó inmediatamente claro para el desarrollador involucrado qué causó la regresión. En la discusión que siguió, habló Wise Carney de AMD. mencionado También puede reproducir la regresión. En lugar de un AMD Ryzen Threadripper de alta gama como el que usa Torvalds, Wyes estaba usando una modesta computadora de escritorio AMD Ryzen 5600G. Una nota importante que mencionó es que esto solo se reproduce si deshabilita ACPI CPPC desde el BIOS y usa ACPI CPUFreq con el gobernador Schedutil.

La mayoría de los sistemas AMD Zen 2 y posteriores son compatibles con ACPI CPPC, por lo que con los núcleos modernos en el lado Ryzen normalmente usan el nuevo controlador AMD P-State. Pero para Zen 2/Zen 3 y sistemas anteriores (o aquellos que desactivan CPPC desde BIOS), el controlador CPUFreq todavía se usa y el regulador de frecuencia de CPU predeterminado suele ser «Schedutil» para aprovechar los datos de uso del programador.

A través de este hilo de la lista de correo, se sugirió una corrección y se discutieron cuestiones específicas de esta regresión. Finalmente, Vincent Guiteau creyó que tenía una solución a la regresión y Wise pudo probar el parche con éxito.

Guittot ya ha sido enviado Programado/Justo: Corrija la selección de frecuencia para casos inestables Como parche para corregir esta mala regresión en el nuevo código de Linux 6.8 cuando se usa ACPI CPUFreq + Schedutil. Explica con corrección:

“Cuando la persistencia de frecuencia no está habilitada, get_capacity_ref_freq(policy) devuelve la frecuencia actual y el margen de rendimiento aplicado por map_util_perf(), lo que permite que el uso supere la capacidad informática máxima y seleccione una frecuencia superior a la frecuencia actual.

El margen de rendimiento ahora se aplica en una etapa temprana del proceso para tener en cuenta algunas limitaciones de uso y no podemos lograr que el uso supere la capacidad informática máxima.

Debemos utilizar una frecuencia superior a la frecuencia actual para tener la posibilidad de establecer un OPP más alto cuando la frecuencia actual se utilice por completo. Aplique el mismo margen y devuelva una frecuencia un 25% mayor que la frecuencia actual para cambiar al siguiente OPP antes de que usemos toda la CPU en el procesador actual”.

En última instancia, fue una solución de código de una línea para abordar esta degradación del rendimiento lo que provocó que las compilaciones del kernel vacío de Linus Torvalds aumentaran de 22 segundos a 44 segundos.

Suponiendo que todo siga funcionando bien con el nuevo parche, la solución debería llegar al código Git de Linux 6.8 una vez que se restablezca Internet y la electricidad de Linus Torvalds.