Ingo Molnar, un conocido desarrollador del kernel de Linux y autor de CFS Task Scheduler propuso para la discusiĆ³n de la lista de correo de desarrollo del kernel de Linux una serie de parches, que afectan a mĆ”s de la mitad de todos los archivos en la fuente del kernel y proporciona un aumento en la velocidad total de reconstrucciĆ³n del nĆŗcleo de 50-80% dependiendo de la configuraciĆ³n.
La optimizaciĆ³n implementada es notable porque estĆ” asociada con la adiciĆ³n del mayor conjunto de cambios en la historia del desarrollo del kernel: se propusieron incluir 2297 parches a la vez, cambiando mĆ”s de 25 mil archivos.
La ganancia de rendimiento se logra cambiando el mƩtodo de manejo de archivos de encabezado. Cabe seƱalar que durante treinta aƱos de desarrollo del kernel, el estado de los archivos de encabezado ha adquirido una forma deprimente debido a la presencia de una gran cantidad de dependencias cruzadas entre archivos.
La reestructuraciĆ³n de los archivos de encabezado tomĆ³ mĆ”s de un aƱo y requiriĆ³ un rediseƱo significativo de la jerarquĆa y las dependencias. Durante la reestructuraciĆ³n, se trabajĆ³ para separar las definiciones de tipo y las API para los diferentes subsistemas del kernel.
Me complace anunciar la primera versiĆ³n pĆŗblica de mi nuevo proyecto Ā«Fast Kernel HeadersĀ» en el que he estado trabajando desde finales de 2020, que es una reelaboraciĆ³n integral de la jerarquĆa de encabezados y las dependencias de encabezados del kernel de Linux , con el doble objetivo de :
ā acelerar la construcciĆ³n del kernel (ambos tiempos absolutos e incrementales de construcciĆ³n)
ā desacoplamiento de tipo del subsistema y la API de definiciones entre sĆ
Como la mayorĆa de los desarrolladores del kernel saben, hay alrededor de ~10,000 encabezados .h principales en el kernel de Linux, en las jerarquĆas include / y arch/*/include/. En los Ćŗltimos mĆ”s de 30 aƱos, se han convertido en un conjunto complicado y doloroso de dependencias cruzadas que llamamos cariƱosamente āInfierno de la dependenciaā.
Entre los cambios realizados se encuentran: separaciĆ³n de archivos de encabezado de alto nivel entre sĆ, exclusiĆ³n de funciones en lĆnea que vinculan archivos de encabezado, asignaciĆ³n de archivos de encabezado para tipos y API, provisiĆ³n de un conjunto separado de archivos de encabezado (alrededor de 80 archivos tenĆan dependencias indirectas que interfieren con el ensamblaje, expuestos a travĆ©s de otros archivos de encabezado), adiciĆ³n automĆ”tica de dependencias a los archivos Ā«.hĀ» y Ā«.cĀ», optimizaciĆ³n paso a paso de los archivos de encabezado, uso del modoĀ»CONFIG_KALLSYMS_FAST=yĀ», consolidaciĆ³n selectiva de archivos C en bloques de ensamblaje para reducir el nĆŗmero de archivos de objetos.
Como resultado, el trabajo realizado permitiĆ³ reducir el tamaƱo de los archivos de encabezado procesados āāen la etapa posterior al preprocesamiento en 1-2 Ć³rdenes de magnitud.
- Por ejemplo, antes de la optimizaciĆ³n, el uso del archivo de encabezado Ā«linux/gfp.hĀ» dio como resultado la adiciĆ³n de 13543 lĆneas de cĆ³digo y la inclusiĆ³n de 303 archivos de encabezado dependientes y despuĆ©s de la optimizaciĆ³n, el tamaƱo se redujo a 181 lĆneas y 26 archivos dependientes.
- Otro ejemplo: al preprocesar el archivo Ā«kernel/pid.cĀ» sin parche, se conectan 94 mil lĆneas de cĆ³digo, la mayorĆa de las cuales no se utilizan en pid.c. Dividir los archivos de encabezado nos permitiĆ³ reducir la cantidad de cĆ³digo procesado tres veces, reduciendo el nĆŗmero de lĆneas procesadas a 36 mil.
Cuando el nĆŗcleo se reconstruyĆ³ por completo con el comando Ā«make -j96 vmlinuxĀ» en el sistema de prueba, la aplicaciĆ³n de los parches mostrĆ³ una reducciĆ³n en el tiempo de compilaciĆ³n de la rama v5.16-rc7 de 231,34 a 129,97 segundos (de 15,5 a 27,7 compilaciones por hora) y tambiĆ©n aumentĆ³ la eficiencia del uso de nĆŗcleos de CPU durante la compilacion.
Con una compilaciĆ³n incremental, el efecto de optimizaciĆ³n es aĆŗn mĆ”s notable: el tiempo para reconstruir el nĆŗcleo despuĆ©s de realizar cambios en los archivos de encabezado se ha reducido significativamente (del 112 % al 173 %, dependiendo del archivo de encabezado que se cambie).
Actualmente, las optimizaciones solo estƔn disponibles para arquitecturas ARM64, MIPS, Sparc y x86 (32 y 64 bits).
Finamente si estƔs interesado en poder conocer mƔs al respecto, puedes consultar los detalles en el siguiente enlace.