Linux 6.12 traerá las optimizaciones de energía para los núcleos híbridos sin HT de Intel Lunar Lake

Lo hecho en Linux con Meteor Lake solo era el paso previo para una mejor gestión de energía en estos procesadores, que como vimos, mejoraron y bastante para un solo parámetro como es EPP. El problema es que Lunar Lake añade un par de cosas nuevas: la Low Power Island a modo de Tile para los E-Core, y el hecho de no tener Hyper Threading en los P-Core. Estos dos cambios, de los tantos que ha traído la arquitectura, cambian el escenario creado para Meteor Lake y requieren nuevas optimizaciones para los núcleos híbridos sin HT. Lo bueno es que con Linux 6.12 estos cambios para Lunar Lake ahora sabemos que se harán realidad.

Están en cola, y eso es una gran noticia, porque estos parches son necesarios para obtener el mejor rendimiento y la mejor potencia y eficiencia, y si no, que se lo digan a Meteor Lake, la cual como arquitectura mejoró un 7% en Linux solo con su último parche EPP, sí, esos parches mágicos que siempre causan mofa, pero que realmente existen.

Linux 6.12 traerá el máximo rendimiento a Lunar Lake mediante el parámetro HWP_HIGHEST_PERF

El objetivo es que el parche llegue antes de la ventana abierta de Linux 6.12, y que con ello, Lunar Lake pueda desplegar todo el potencial en cuanto a rendimiento y eficiencia dentro de los estados P, los cuales ahora mismo no están correctamente leídos por el SO debido a las dos principales novedades en este sentido que hemos visto arriba.

Sea como fuere, el parche comenta lo siguiente:

"Si el sistema dado es híbrido y no tiene SMT, el nuevo código deshabilita el soporte ITMT en el programador (porque puede interferir con el código de capacidad de CPU asimétrica en el programador que se habilita automáticamente al configurar la capacidad de CPU asimétrica) después de inicializar todas las CPU y encuentra la que tiene el valor máximo de HWP_HIGHEST_PERF. A continuación, calcula el número de capacidad para cada CPU dividiendo el producto de su HWP_HIGHEST_PERF y SCHED_CAPACITY_SCALE por el HWP_HIGHEST_PERF máximo.

Cuando una CPU se desconecta, su capacidad se restablece a SCHED_CAPACITY_SCALE y, si es la que tiene el valor máximo de HWP_HIGHEST_PERF, se vuelven a calcular los números de capacidad para todas las demás CPU. Esto también se encarga de una limpieza durante los cambios de modo de operación del controlador.

De manera análoga, cuando una nueva CPU se conecta, su número de capacidad se actualiza y, si su valor HWP_HIGHEST_PERF es mayor que el máximo actual, se vuelven a calcular los números de capacidad para todas las demás CPU en línea".

Otro parche más en camino, esta vez, para que los estados calculen correctamente la frecuencia de la CPU

De nuevo y una vez más, el que posiblemente es uno de los ingenieros más conocidos de Intel para este SO, Rafael Wysocki, comenta que hay otro parche en cola para que el SO sepa escalar correctamente en frecuencias para la CPU, y dice lo siguiente:

"Para poder calcular los tamaños de las tareas de manera consistente en todas las CPU de un sistema híbrido, es necesario proporcionar información de escalado de la capacidad de la CPU al programador a través de arch_scale_cpu_capacity(). Además, el valor devuelto por arch_scale_freq_capacity() para la CPU dada debe corresponder al valor de retorno de arch_scale_cpu_capacity() para ella, o los cálculos de utilización serán inexactos.

Hay que agregar soporte para ello a través de variables por CPU que contengan la capacidad y la relación de frecuencia máxima a la frecuencia base (por SCHED_CAPACITY_SCALE) que serán devueltas por arch_scale_cpu_capacity() y utilizadas por scale_freq_tick() para calcular arch_freq_scale para la CPU actual, respectivamente.

Para evitar agregar una sobrecarga medible para los sistemas x86 no híbridos, que son la gran mayoría actualmente, el nuevo escalado de la capacidad de la CPU híbrida debe estar vigente o no que se controle mediante una clave estática.

Esta clave estática se establece llamando a arch_enable_hybrid_capacity_scale(), que también asigna memoria para los datos por CPU y los inicializa. A continuación, se utiliza arch_set_cpu_capacity() para establecer las variables por CPU mencionadas anteriormente para cada CPU y es necesario llamar a arch_rebuild_sched_domains() para que el programador se dé cuenta de que se puede utilizar la programación basada en capacidad en el futuro.

En resumen, no se deben tener muy en cuenta los datos que salgan de las CPU Lunar Lake en Linux hasta que llegue dicha versión 6.12, donde entonces se podrán comparar de tú a tú con Strix Point y ver qué tal afecta el SO al rendimiento y la eficiencia en ambas arquitecturas.