jordi1986 escribió:Aunque no estoy en ese punto, me supera por bastante. Mi duda es, cuando sale una actu de kernel entonces que haces? puedes actualizar solo la parte que afecta a tu hardware? No vale la pena actualizarlo en tu caso porque ya lo tienes customizado? como funciona dejándolo afinado como lo tienes tú?
Cuando sale una nueva versión en kernel.org lo que hago es descargo el tarball (el .tar.gz) en local, y con mi .config que lo tengo publicado, hago un make olddefconfig, a veces añaden parámetros nuevos o quitan alguno que tenga, aunque la mayoría de las veces es mejorar lo existente o correcciones de seguridad, en ese caso me toca prueba y error hasta que lo dejo afinado, pero ir actualizando en las reléase dentro de la misma rama de versión 7.3.x pocas veces ya toca hacer grandes cambios, es mas el cambio entre 6.19.x a 7.x, el trabajo gordo de limpieza ya lo hice, no tengo que repetirlo, tengo soporte para mi hardware, Al final, lo que he hecho ha sido meterle el bisturí al kernel original para crear algo específico para mi hardware. La diferencia real frente al kernel genérico que te viene por defecto en cualquier distribución se resume en esto:
• Reducción del 94% en módulos y drivers: El kernel de stock de debian viene con más de 4.000 módulos para que funcione en cualquier PC. El mío lo he recortado a solo 233 módulos esenciales para mi equipo de sobremesa con Ryzen y 255 para el portátil Lenovo t440p. He eliminado miles de líneas de configuración que jamás voy a usar, como drivers de televisión DVB, sintonizadoras, buses obsoletos o tarjetas de red de otros fabricantes, soporte a otras CPUs..
• Compilación nativa por hardware (No genérica): Las distribuciones compilan en formato x86-64 genérico para asegurar compatibilidad antigua. Yo optimizo el kernel indicándole las instrucciones reales de mi CPU y forzando al compilador a usar la arquitectura concreta de mis chips (Zen 3 para el Ryzen 9 y Haswell para el portátil). El sistema aprovecha directamente las extensiones vectoriales y criptográficas reales del procesador (AVX2, AES-NI), por lo que el código vuela.
• Optimización y Seguridad Real: He ajustado el planificador al número exacto de hilos de mis CPUs (32 y 8 hilos) para eliminar sobrecarga de software, he bajado la latencia al mínimo para juegos y escritorio, y he optimizado la gestión de la memoria RAM y la gráfica. Todo esto manteniendo las mitigaciones de seguridad de la CPU activas y firmando los módulos con una clave propia para que funcione con el Secure Boot de la placa base activado.
En resumen: no he inventado código nuevo, sino que he realizado una mega limpieza de configuración para adaptarlo a mi hardware real, y de paso meter cosillas como las mejoras de cachyOS, criptografía, etc… El resultado es un kernel muchísimo más ligero, que consume menos RAM estática, arranca al instante y aprovecha cada ciclo de mi silicio en lugar de ejecutar instrucciones genéricas.
Además, como muchas veces no compilo en local, he automatizado el proceso en Github, para te hagas una idea he pasado de poco más de media hora en Ryzen con config base de debian, a casi 3 minutos de compilación, y en el Lenovo de casi 45 minutos a solo 14 en local.
En Github los runners tienen 4 cores y para tener una réplica 1:1 despliego un contenedor debian en el runner y dentro de él hago la compilación, resultado los .deb listos para instalar y con los módulos ya firmados.
Al compilador le paso estos flags:
• -march=haswell / -march=znver3: Es la más importante. Fuerza al compilador a usar las instrucciones avanzadas exclusivas de las CPUs (AVX2, BMI2, criptografía por hardware… en lugar de instrucciones genericas). El kernel resultante rinde al máximo, pero solo arrancará en esa arquitectura.
• -mtune=haswell / -mtune=znver3: Reorganiza el código internamente para que se ejecute de la forma más eficiente posible según las reglas de los pipelines de esa CPU concreta.
• -O2: Activa el nivel estándar de optimización de rendimiento de Linux, buscando el mejor equilibrio entre velocidad del código y estabilidad.
• -pipe: Acelera el proceso de compilación haciendo que las distintas fases de GCC se comuniquen a través de la memoria RAM en lugar de escribir archivos temporales en el disco, se gana mucha velocidad de compilación.
Para quien quiera curiosearlo, replicarlo o mejorarlo
https://github.com/azagramac/linux-kernel 
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
