Comprobar que Kernel de linux detecte y gestione e-cores

Puede ser que el kernel de linux no detecte los e-cores como debe, no es que no los detecte y estén des-habilitado, si no que detecta todos los cores iguales y no hace distinción de ello.

Veamos cpu_capacity, aquí deberían haber variaciones pero no las hay.

# grep . /sys/devices/system/cpu/cpu*/cpu_capacity
/sys/devices/system/cpu/cpu0/cpu_capacity:1024
/sys/devices/system/cpu/cpu10/cpu_capacity:1024
/sys/devices/system/cpu/cpu11/cpu_capacity:1024
/sys/devices/system/cpu/cpu12/cpu_capacity:1024
/sys/devices/system/cpu/cpu13/cpu_capacity:1024
/sys/devices/system/cpu/cpu14/cpu_capacity:1024
/sys/devices/system/cpu/cpu15/cpu_capacity:1024
/sys/devices/system/cpu/cpu1/cpu_capacity:1024
/sys/devices/system/cpu/cpu2/cpu_capacity:1024
/sys/devices/system/cpu/cpu3/cpu_capacity:1024
/sys/devices/system/cpu/cpu4/cpu_capacity:1024
/sys/devices/system/cpu/cpu5/cpu_capacity:1024
/sys/devices/system/cpu/cpu6/cpu_capacity:1024
/sys/devices/system/cpu/cpu7/cpu_capacity:1024
/sys/devices/system/cpu/cpu8/cpu_capacity:1024
/sys/devices/system/cpu/cpu9/cpu_capacity:1024

Los e-cores, deben tener un valor más bajo para que el kernel decida darles las tareas de menor prioridad, que el kernel vea la capacidad de todos por igual es un problema.

EDIT: He estado leyendo y resulta que cpu_capacity es un valor que el kernel usa casi exclusivamente en arquitectura ARM . En Intel x86, el kernel confía más en el HFI y en las tablas ACPI, por eso aunque marque 1024 en todos, el Scheduler no se deja engañar, por eso más abajo vemos que esto solo aparece en 6.17.x en debian testing y seǵun la actualización desaparece....

Mas info:
https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/cpu-capacity.txt

Sin embargo intel_pstate esta habilitado

# cat /sys/devices/system/cpu/intel_pstate/status
active

En la documentación ya dice algo más interesante y no solo de ARM https://docs.kernel.org/scheduler/sched-capacity.html

Conventional, homogeneous SMP platforms are composed of purely identical CPUs. Heterogeneous platforms on the other hand are composed of CPUs with different performance characteristics - on such platforms, not all CPUs can be considered equal.

CPU capacity is a measure of the performance a CPU can reach, normalized against the most performant CPU in the system. Heterogeneous systems are also called asymmetric CPU capacity systems, as they contain CPUs of different capacities.

Disparity in maximum attainable performance (IOW in maximum CPU capacity) stems from two factors:

• not all CPUs may have the same microarchitecture (µarch).

• with Dynamic Voltage and Frequency Scaling (DVFS), not all CPUs may be physically able to attain the higher Operating Performance Points (OPP).

El kernel parece que tiene HFI :

# zgrep CONFIG_INTEL_HFI_THERMAL /boot/config-$(uname -r)
CONFIG_INTEL_HFI_THERMAL=y

Highest_perf nos da el mismo valor en todos los cores:

cat /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf
255
255
255
255
255
255
255
255
255
255
255
255
255
255
255
255

Esto seǵun parece ya depende un poco de la BIOS, pero en la placa asus no he podido ver ninguna opción que lo cambie, o sea la BIOS manda la info de todos los cores iguales y luego el kernel parece que hace lo suyo ( tampoco esta muy claro que esto debería ser así y no encontré más info. )

Todo indica que los módulos para que e-cores y p-cores se diferencien están habilitados, pero el sistema a la vez nos dice que todos los CPU tienen misma prioridad, así que esto independientemente de como se vea, si el kernel tiene Hardware P-States activado ( que ya vimos antes que si ) debería gestionar bien los e-cores.

Dirán, claro el CPU no tiene e-cores, pero estamos hablando de:

12th Gen Intel(R) Core(TM) i5-12600KF

Veamos más allá, desde el punto de vista del kernel ¿como sabemos que tiene 16 hilos o 16 cores pelado ? y como diferenciamos los 6 p-cores con 2 hilos cada uno y los 4 e-cores de 1 hilo

¿ Como ver los cores / hilos etc ?

De toda la vida eso se ha visto en el core ID, aunque top diga tienes 16 hilos, realmente es por que hay un core físico y un core que no es físico ( explicación majestuosa  XD )  en el TOP y en el estado vemos 16 pero es por que el sistema cuenta los hilos, normalmente esto siempre ha sido 8 core y 8 hilos = 8c/16t ahora es un poco distinto podemos verlo así:

# cat /proc/cpuinfo | grep "core id"
core id        : 0 
core id        : 0 
core id        : 4 
core id        : 4 
core id        : 8
core id        : 8
core id        : 12
core id        : 12
core id        : 16
core id        : 16
core id        : 20
core id        : 20
core id        : 28
core id        : 29
core id        : 30
core id        : 31

Como vemos hay cores con el mismo ID, eso es un core + el hilo, aquí explicado:

# cat /proc/cpuinfo | grep "core id"
core id        : 0  p-Core 1
core id        : 0  HIlo de p-Core 1
core id        : 4  p-Core 2
core id        : 4  Hilo de p-Core 2
core id        : 8  p-Core 3
core id        : 8  Hilo dep-Core 3
core id        : 12  p-Core 4
core id        : 12  Hilo de p-Core 4
core id        : 16  p-Core 5
core id        : 16  Hilo de p-Core 5
core id        : 20  p-Core 6
core id        : 20  Hilo de p-Core 6
core id        : 28  e-core 1 sin hilo
core id        : 29  e-core 2 sin hilo
core id        : 30  e-core 3 sin hilo
core id        : 31  e-core 4 sin hilo

Los e-cores tienen un único id ya que no tienen hilos, esto básicamente nos da

6c / 12t ( p-cores ) y 4c ( e-cores ) = 16 hilos en total.

Y así cuando hacemos TOP / BTOP / HTOP o lscpu nos muestra 16 hilos:

Gráfico CPU híbrido de intel ( i5 12600kF )

Todo lo que has leído antes se resume en este gráfico, además de algo que no se menciono, la cache en el CPU hibyrido

L1, cada core e-core y p-core tiene su propio L1

L2, los p-cores tiene su propio L2 y los e-cores comparten L2

L3 tanto e-cores como p-cores comparten L3

Bien aclarado este tema que no venia a cuento seguimos...

Comprobar que el thread director de intel esta activado y vemos si el modulo esta instalado y cargado:

Se detecta el 

#  ls /sys/bus/acpi/devices | grep INTC1070

INTC1070:00

El micro código esta instalado y presente:

# dpkg --get-selections |grep microcode
amd64-microcode					install
intel-microcode					install

# grep -E "CONFIG_MICROCODE|CONFIG_MICROCODE_INTEL" /boot/config-$(uname -r)
CONFIG_MICROCODE=y
# CONFIG_MICROCODE_LATE_LOADING is not set

ls -l /lib/firmware/intel-ucode/06-97-02
-rw-r--r-- 1 root root 226304 nov 13 16:48 /lib/firmware/intel-ucode/06-97-02

Podemos verlo aquí: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases

Todo indica que tenemos todo instalado, incluso he habilitado algunas opciones en la bios, pero el kernel sigue dando la misma prioridad a todos los cores.

Esa es la duda, aunque el anterior POST hemos visto como cargas de trabajo altas no tocan los e-cores casi, así que en principio esta bien pero la prioridad parece la misma, aunque tengo que investigar si la prioridad puede cambiar solo en altas cargas, pero ese casí me raya un poco, así que iremos por la verdad...

cpu_capacity no existe en 6.12 al menos no en mi debian.

Luego, revisando cpufreq vemos la frecuencia de cada core, aun que verlo ahí no nos afecta en nada, o sea la frecuencia es la que tiene, pero esto no le dice al kernel que usar en cada momento.

cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq 
4900000
4900000
4900000
3600000
3600000
3600000
3600000
4900000
4900000
4900000
4900000
4900000
4900000
4900000
4900000
4900000

Diferencias ligeras entre kernel 6.12 y 6.17 en system/cpu

Kernel 6.12 versión por defecto de Debian 13

Kernel 6.17 instalado después en la rama testing

Y aquí algunas diferencias:

/sys/devices/system/cpu/cpu5

$ diff 6.12 6.17
63a64
> ├── cpu_capacity
195c196
< 27 directories, 165 files
---
> 27 directories, 166 files

En la carpeta de CPU en 6.12 no existe el fichero cpu_capacity cosa que es correcto, ya que vimos antes que era de ARM, pero en la 6.17 si... así que esa parte no la tengo del todo clara, tendré que leer más.

Justo he mirado y tengo una actualización del kernel en debian testing, vamos a actualizar a ver linux-base-6.18.5

Versión actual: 6.17

Versión Nueva 6.18.5

Se quedo sin espacio boot y ya he escrito un articulo sobre como solventarlo bastante rápido sin desinstalar nada..

Ahora en el kernel 6.18.5 la historia cambia, cpu_nfo_maxfreq ya no esta:

cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq 
cat: '/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq ': No existe el fichero o el directorio

Pero según el dmesg el kernel hace lo que dice la documentación del kernel que pace más arriba

Diferencia los nucleos:

[ 0.044535] Performance Events: ... Alderlake Hybrid events, 32-deep LBR, full-width counters, Intel PMU driver.

Luego detecta los e_core (atom ) y los cpu core ( p-core)

[    0.044535] core: cpu_core PMU driver: 
[    0.010133] core: cpu_atom PMU driver: 

También detecta el Thread Director :

[ 0.398875] intel_pstate: Intel P-state driver initializing
[ 0.400385] intel_pstate: HWP enabled

Aquí hay un dato histórico, popularmente se les conoce como e-core, pero internamente son como los ATOM, aquellos CPU super ligeros de bajo consumo de intel que metía sobre todo en portatiles, básicamente es un core de atom metido en un cpu normal pero potenciado. ya que generan menos calor, consumen menos etc, aunque estos llegan a 3.9GHz y antes creo que no pasaban de 1.8 aunque no me hagas mucho caso y búscalo en google

Mi conclusión después de revisar todo, es que parece que todo funciona, aunque se ven datos distintos entre las versiones 6.12 y las 6.17 / 6.18, faltan ficheros en sys/devices  que no muestran determinados valores.

Todo parece OK, y si bien grub habilita HFI no lo veo en el dmesg aunque este HWP, por lo tanto toca ver si el kernel generico no tiene soporte total para e-cores y p-cores para no romper algunos instalaciones que no tengan estos nucles.

Así que vamos a compilar el kernel ( luego en otro hilo documentaré el proceso si no este se vuelve eterno )

Compilando 6.19 para debian sin basura

Basura= hardware viejo, soporte para AMD, soporte para cosas que ni existen etc hay más de 10 mil drivers en en el kernel para dar soporte a miles de ordenadores distintos, aquí como necesitamos a lo sumo 30 drivers compilaremos esos solo.

He compilado y sin noveades, todo funciona igual...

Pero también he comprobado que todo funciona bien, los e-cores trabajan con procesos de bajo nivel casi siempre y esos procesos no suelen tocar p-cores, como XORG

Durante la compilacion he monitorizado los bailes ( cambios de core de los procesos a nivel de micro segundos, no como en TOP pueden ver más de esta info en este hilo :

e-cores y p-cores en linux

Prueba Final, e-cores y p-cores funcionando en linux para lo que fueron hechos:

Dejo una imagen que en este caso vale más que un millon de palabras, he limpiado el ruido de todos los demás procesos, esta cc1 en color azul saltando de cores y se mantiene en p-cores ( esta consumiendo 100% de CPU de 4 hilos, esto no se ve ya que no estamos midiendo uso de CPU si no los saltos de core y en que core se esta ejecutando )

Y luego esta XORG que se mantiene en los e-cores, el consumo es nulo, pero XORG se encarga del entorno gráfico así que tiene muchos saltos de CORE y cambios de estado y por eso vemos muchos más puntos

XORG vs CC1 en Arquitectura híbrida 

XORG esta en todo lado, las ventas están siempre activas en momentos puntuales necesitan más poder y pasan a p-cores.

Esto confirma que los e-cores se encargan de lo ligero

Dejo la última imagen, con más procesos, chrome, terminal, marco ( gestor de vantanas de mate ) xorg ( el que dibuja las ventajas )  y cc1 mientras se compilaba el kernel

Se ve claramente lo pesado en los p-cores y lo ligero en los e-cores y en momentos puntuales en p-cores.

Eficiencia pura del kernel moviendo de un sitio a otro cosas y decidiendo donde mandar que para ahorrar energía, generar menos calor etc

Conclusión:

Al inicio veíamos como  cpu_capacity tiene la misma capacidad aunque en todo lado dice que debería ser distinta, ,pero al final estamos viendo que linux esta gestionando bien los e-cores y p-cores

Así que o ha cambiado algo en el kernel o la documentación es más antigua y los comentarios en los foros son de otras versiones, pero en la rama 6.18.x y en la 6.19.x todo parece estar bien.