La cuarta candidata de lanzamiento de Linux 7.0-rc4 ya está disponible y llega en un momento clave del ciclo de desarrollo del nuevo kernel. A pesar de encontrarnos en una fase en la que, en teoría, las novedades deberían ir reduciéndose, esta RC vuelve a destacar por un volumen de cambios más alto de lo que suele ser normal a estas alturas.

Desde el propio proyecto reconocen que las últimas tres RC han sido más grandes de lo habitual, algo que está generando cierta inquietud entre los desarrolladores. Aun así, la sensación general es que se trata sobre todo de pequeños parches y ajustes repartidos por todo el núcleo, enfocados a mejorar estabilidad, rendimiento y compatibilidad de cara al lanzamiento final previsto para dentro de aproximadamente un mes.

Linux 7.0-rc4: una RC más voluminosa de lo esperado

En el calendario del kernel, la Release Candidate 4 suele marcar el inicio de la fase más tranquila, cuando se supone que el desarrollo se centra en pulir detalles y reducir al mínimo los cambios de calado. Sin embargo, para Linux 7.0 está ocurriendo justo lo contrario: las RC2, Linux 7.0-rc3 y ahora RC4 siguen siendo algo más grandes que las de ciclos anteriores.

Linus Torvalds ha explicado que gran parte del volumen se concentra al final de cada semana: el jueves llega el gran paquete de cambios de red, y el viernes se acumula el resto de trabajo enviado por los distintos mantenedores, con algunos parches rezagados entrando durante el fin de semana. El resultado es que lo que parecía una semana tranquila se convierte, casi de golpe, en otra RC de tamaño superior a la media.

El propio Torvalds apunta a un posible efecto psicológico: el salto a un nuevo número de versión mayor podría estar animando a muchos desarrolladores a mover más cambios de lo habitual. Aun así, insiste en que, aunque las cifras sean algo más altas, el tipo de modificaciones que se están integrando son, en su mayoría, retoques pequeños y bastante benignos.

Correcciones críticas en el scheduler mm/cid

Uno de los focos principales de Linux 7.0-rc4 está en el planificador del kernel, concretamente en el código asociado a mm/cid. Este subsistema fue reescrito hace unos meses, y desde entonces ha ido arrastrando diferentes regresiones que han afectado tanto a la estabilidad como al rendimiento, especialmente en máquinas grandes.

En esta RC se han incluido varios parches de la rama «sched/urgent» para resolver cuelgues y condiciones de carrera vinculados a la gestión de CIDs. Entre los problemas que se corrigen destacan:

• Bloqueos derivados de una carrera entre forks concurrentes, que podían desembocar en situaciones de espera indefinida.
• Un fallo en la combinación vfork()/CLONE_VM que, bajo ciertas circunstancias, generaba cuelgues difíciles de reproducir.
• La eliminación de una protección de preempción innecesaria que complicaba el flujo de ejecución sin aportar beneficios reales.
• Un ajuste importante en la forma en que se recorre la lista de tareas para fijar CIDs a CPUs, sustituyendo una lógica de conteo conocida por ser lenta y frágil por una lista más simple basada en nodos, con impacto directo en el rendimiento de sistemas con muchos núcleos.

Con estos cambios, el objetivo es recuperar el rendimiento perdido en sistemas de gran tamaño desde versiones anteriores (la regresión se arrastraba desde la serie 6.19) y, al mismo tiempo, reducir la probabilidad de cuelgues en escenarios de alta concurrencia, como servidores, centros de datos o infraestructuras virtualizadas.

Arreglo de una regresión de rendimiento en sistemas grandes

Más allá de los cuelgues, se había detectado una pérdida de rendimiento en equipos con muchos hilos de ejecución o bajo cargas intensivas de procesos. Esta regresión estaba vinculada al recorrido de la lista de tareas dentro del planificador, que introducía un coste adicional apreciable en entornos de gran escala.

Los parches incluidos en Linux 7.0-rc4 optimizan esta ruta crítica, eliminando la lógica de conteo lenta y sustituyéndola por estructuras más eficientes para asociar CIDs y CPUs. En la práctica, esto debería devolver a los grandes servidores, estaciones de trabajo de alto rendimiento y sistemas con gran densidad de procesos a los niveles de rendimiento esperados.

Más estabilidad en suspensión y reanudación en x86

Además de los ajustes en el scheduler, esta RC incorpora una corrección relevante en la arquitectura x86 dirigida a evitar cuelgues al reanudar desde suspensión a RAM (s2ram) en algunos sistemas.

El problema se producía cuando el firmware reactivaba el modo x2APIC durante la reanudación, pese a que el kernel lo había deshabilitado en el arranque por falta de soporte de remapeo de IRQ u otros motivos. En ese escenario, el kernel seguía usando la interfaz xAPIC mientras el hardware funcionaba en x2APIC, lo que podía provocar bloqueos nada más salir de suspensión.

Para solucionarlo, se ha ajustado el proceso de reanudación en lapic_resume() de forma que, si el kernel espera que x2APIC siga desactivado, lo vuelva a deshabilitar explícitamente si el firmware lo ha encendido por su cuenta. Este cambio debería mejorar la fiabilidad de la suspensión en configuraciones x86 afectadas, algo especialmente relevante en portátiles y equipos de escritorio en entornos de trabajo europeos donde el ahorro energético mediante suspensión es habitual.

Importante corrección en AMDGPU para GPUs RDNA4

En el terreno gráfico, Linux 7.0-rc4 trae un parche clave para el controlador AMDGPU orientado a tarjetas con arquitectura RDNA4. El fallo detectado se manifestaba tras ejecutar cargas intensivas de computación, como tareas de inteligencia artificial, inferencia con modelos como Llama.cpp u otros trabajos GPGPU exigentes.

En estos escenarios, la GPU podía quedarse atrapada en un estado de energía incorrecto al volver al reposo, manteniendo un consumo superior al necesario o gestionando mal las transiciones de potencia. Con el nuevo parche, se mejora la lógica de retorno al estado idle, lo que debería reducir consumos innecesarios cuando finaliza el trabajo pesado.

Para usuarios europeos que utilizan Linux en estaciones de trabajo, servidores de IA o clústeres de cómputo con hardware AMD, esta corrección supone un avance relevante tanto en términos de eficiencia energética como de estabilidad operativa, especialmente en centros de datos donde cada vatio cuenta.

Mejoras en cpupower y gestión energética con systemd

Otro de los frentes de esta RC se centra en la herramienta cpupower, integrada en el árbol del kernel, que recibe varias mejoras orientadas a la gestión de energía y al comportamiento de la CPU.

La novedad más destacada es que el servicio systemd asociado a cpupower permite ahora configurar el parámetro EPP (Energy Performance Preference). A través del archivo cpupower-service.conf, es posible ajustar este valor para equilibrar mejor rendimiento y eficiencia energética, de forma similar a ejecutar manualmente cpupower set -e con la preferencia deseada.

Este cambio facilita que distribuciones y administradores europeos puedan perfilar su infraestructura según diferentes usos: desde portátiles donde prima la autonomía hasta servidores donde se busca el máximo rendimiento, pasando por entornos mixtos en oficinas o centros educativos.

Además, se ha corregido el reporte del estado de Turbo Boost en plataformas Intel. Hasta ahora, cpupower indicaba que Turbo estaba activo incluso cuando estaba deshabilitado en el sistema. Con las nuevas modificaciones, la herramienta consulta correctamente al controlador intel_pstate y refleja el estado real al usar la opción –boost, lo que aporta información más fiable a la hora de ajustar políticas de energía.

Rust gana peso: preparativos para futuras versiones

La integración de Rust en el desarrollo del kernel Linux continúa avanzando paso a paso en esta RC. El equipo responsable ha enviado una nueva tanda de cambios en la infraestructura y el toolchain de Rust que ya han sido aceptados en la rama principal, con la vista puesta en futuras versiones del compilador.

Entre las novedades más relevantes se encuentran ajustes para mejorar la reproducibilidad de las compilaciones y evitar el uso de rutas absolutas. A partir de Rust 1.95 se introducen mecanismos de remapeo de rutas para que el binario resultante no contenga caminos absolutos del sistema de archivos, lo que contribuye a reproducir builds de forma más consistente y sin filtrar información innecesaria sobre el entorno de compilación.

También se han incluido cambios para adaptarse a Rust 1.96, como permitir el nuevo lint unused_features sin que suponga un problema para el código del kernel. Además, se han eliminado enfoques antiguos en la generación de ficheros de dependencias, emitiendo ahora la información directamente en $(depfile) sin recurrir a archivos temporales .d.

A nivel de código, se han aplicado pequeñas correcciones en el crate ‘kernel’ (por ejemplo, en el módulo str para evitar advertencias cuando CONFIG_BLOCK está desactivado, o en el módulo cpufreq para suprimir falsos positivos de Clippy) y en el crate pin-init, donde se ha retirado un atributo considerado inseguro y se ha documentado mejor la importancia de los accesores de campos para mantener la solidez del modelo.

Todo este trabajo no implica cambios visibles para el usuario final europeo a corto plazo, pero refuerza la base para que Rust tenga un papel cada vez más relevante dentro del kernel, algo que puede traducirse en menos errores de memoria y mayor seguridad en el futuro.

Calendario de lanzamiento y papel en las distribuciones

Con esta cuarta RC ya en la calle, el horizonte para la versión estable de Linux 7.0 se sitúa en aproximadamente un mes. Si el ritmo de correcciones se mantiene y no aparecen problemas graves de última hora, el núcleo definitivo debería estar listo hacia mediados de abril.

Esta fecha encaja muy bien con los calendarios de distribuciones clave en Europa. Ubuntu 26.04 LTS y Fedora 44, previstas también para esa franja temporal, apuntan a incluir Linux 7.0 como kernel de referencia. Para empresas, administraciones públicas y usuarios avanzados en España y el resto del continente que dependen de estas distribuciones, esto significa que buena parte de las mejoras de estabilidad, rendimiento y energía descritas llegarán integradas de serie en sus próximas instalaciones.

En el ecosistema Rolling Release, como Arch Linux o openSUSE Tumbleweed, la adopción de Linux 7.0 será previsiblemente muy rápida, con paquetes disponibles prácticamente desde el primer día. En cambio, otras distribuciones más conservadoras podrían tardar algo más en incorporarlo, o bien ofrecerlo como kernel alternativo para quienes quieran actualizar manualmente.

Con el lanzamiento estable de Linux 7.0 a la vuelta de la esquina y una RC4 que sigue acumulando ajustes en áreas clave como el scheduler, la gestión energética, el soporte de GPUs AMD y la infraestructura Rust, todo apunta a que las próximas semanas serán decisivas para terminar de afinar el núcleo que impulsará buena parte de las distribuciones de referencia en España y Europa durante los próximos años.