El kernel de Linux probará elegir núcleos inactivos al azar para repartir mejor la carga
Arm propone aleatorizar la elección entre núcleos idle equivalentes en el planificador de Linux. En un Ampere Altra de 160 núcleos mide unos pocos puntos de mejora en Stress-NG.
Christian Loehle, ingeniero de Arm, ha enviado a la lista de correo del kernel la serie de parches que cambia una decisión muy concreta del planificador: cuando varias CPU están inactivas y anuncian la misma latencia de salida, el código deja de quedarse con la primera y las sortea. Sobre un Ampere Altra doble, ya veterano, de 160 núcleos mide mejoras de unos pocos puntos porcentuales de rendimiento en Stress-NG. Los parches están en revisión, no en el árbol principal.
Lo que ataca es un sesgo de orden de recorrido. El selector de camino lento prefiere la CPU que lleva menos tiempo inactiva, como proxy de que su caché sigue caliente, y ese dato lo da idle_stamp. El problema es que idle_stamp no registra la entrada en curso de CPUIdle, así que una CPU que lleva más rato idle también puede estar volviendo a entrar. Con dos tareas despertando a la vez, ambos selectores pueden elegir la misma CPU antes de que ninguna se haya encolado.
La elección del primero elegible, además, puede acabar favoreciendo a la CPU con mayor coste de despertar. Entre dos con la misma latencia anunciada, si la entrada no se puede abortar hay que terminarla y luego salir, mientras que una ya residente solo tiene que salir: la latencia anunciada cubre los dos casos por igual.
Cómo lo resuelve
Loehle mete reservoir sampling en la rama de empate y reinicia el contador de candidatos cuando aparece una latencia de salida menor. Para el sorteo usa el PRNG del planificador por CPU y reciprocal_scale(), con lo que evita divisiones variables y un segundo recorrido. El resultado, según el propio parche, reduce la convergencia determinista sin reservar la CPU que se elige.
Quedan dudas razonables. Las primeras preguntas en la lista van sobre si la aleatoriedad aporta algo en equipos con pocos núcleos, donde el sesgo importa menos. También está sobre la mesa que introducir azar en esta decisión haga el comportamiento menos predecible, algo que en planificación no siempre se acepta con gusto.
Hoy el escenario donde puede notarse es el de muchos núcleos por socket, y la tendencia no para: AMD anuncia hasta 256 por zócalo en su serie EPYC 9006. Si el sesgo de orden de recorrido no se corrige por otra vía, sortear entre candidatos iguales es una forma barata de repartir la carga.
