Intel mejorará el rendimiento y eficiencia de sus CPU híbridas con 3 parches para el driver P-State en Linux
Cuando salió Meteor Lake al mercado desde Linux se vio que algo no terminaba de ir bien. Algunos parches después Intel consiguió el rendimiento que esperaba y se puso por delante de AMD por la mínima en CPU, además, con una eficiencia más elevada. A diferencia de los rojos, que estrenarán núcleos híbridos con Zen 5 para casi todas las plataformas, Intel lo hizo antes y eso significa que en Linux los parches, drivers y Kernel tuvieron que adaptarse. Por ello, ahora Intel ha presentado lo que será una serie de 3 parches para lograr un mejor desempeño con los P-State en Linux mediante nuevos drivers.
Según informa Phoronix y podemos ver en el repositorio del kernel de Linux, a finales del mes pasado Rafael Wysocki, Programador informático y líder de proyectos de software en Intel, lanzó la petición sobre tres parches que deben terminar en un mejor rendimiento y eficiencia para cualquier procesador con núcleos híbridos dentro de x86 y este SO, pero, ¿de qué tratan realmente?
El Kernel de Linux funcionará mejor gracias a tres partes y un driver para los P-State de las CPU Intel híbridas
La información asimétrica como concepto que vamos a ver a continuación según ha deslizado el propio Wysocki no es más que la capacidad del software por entender, mover y trabajar la información entre varios tipos de núcleos. En este caso y como sabemos, P-Core y E-Core, así como los LP-E que también formarían parte de los segundos.
Por ello, Vysocki habla sobre estos parches diciendo que:
El propósito y objetivo de esta serie es proporcionar al programador información asimétrica sobre la capacidad de la CPU en sistemas híbridos x86 basados en hardware Intel. La información asimétrica sobre la capacidad de la CPU es importante en los sistemas híbridos, ya que permite calcular la utilización de las tareas de forma coherente en todas las CPU del sistema, independientemente de su capacidad.
Esto, a su vez, permite al gobernador "schedutil cpufreq" establecer niveles de rendimiento de la CPU de manera consistente en los casos en que las tareas migran entre CPU de diferentes capacidades. También debería ayudar a mejorar la asignación de tareas y las decisiones de equilibrio de carga en sistemas híbridos y es clave para cualquier cosa relacionada con EAS.
La información en cuestión proviene del registro "MSR_HWP_CAPABILITIES" y el driver "intel_pstate" los cuales proporcionan al programador lo necesario según el changelog del parche [3/3]. El parche [2/3] presenta la infraestructura arch necesaria para eso (en forma de una variable de capacidad por CPU) y el parche [1/3] es un ajuste de código preliminar.
No todo son ventajas, habrá un ligero overhead y sobrecarga en el acceso a la memoria
Vysocki afirma que hay una ligera contraparte, que por otro lado, no debería afectar al aumento de rendimiento realmente:
Los cambios realizados por el parche [2/3] son muy simples, es por eso que esta serie se envía como RFC. Es decir, aumenta el overhead tanto en los sistemas híbridos como no híbridos, lo que puede considerarse objetable, aunque podría decirse que el aumento de los gastos generales no es significativo.
La sobrecarga de memoria es una variable "long" sin firmar por la CPU que no es muy IMV y también hay una sobrecarga de acceso a la memoria adicional en cada sitio de "call arch_scale_cpu_capacity()" que, sin embargo, no espero que se note. En cualquier caso, la sobrecarga adicional se puede evitar a costa de hacer el código un poco más complejo (por ejemplo, la memoria adicional por CPU se puede asignar dinámicamente solo en sistemas híbridos y se puede usar una rama estática para permitir el acceso a él cuando sea necesario).
Simplemente no estoy seguro de si la complejidad adicional realmente vale la pena, así que me gustaría conocer la opinión de los mantenedores de x86 al respecto.