n

La publicación de Linux 6.19-rc1 marca el cierre de la ventana de integración de esta versión del kernel y deja ver por dónde irán los tiros en los próximos meses. Aunque todavía se trata de una fase temprana del ciclo, ya se observan cambios de calado en subsistemas clave, nuevas arquitecturas soportadas y un impacto apreciable en el rendimiento según las primeras pruebas comparativas frente a Linux 6.18 estable.

La versión candidata llega además en un contexto algo peculiar: Linus Torvalds ha adelantado unas horas el anuncio porque se encuentra en Japón, donde ha asistido a la Linux Plumbers Conference y al Linux Kernel Maintainer Summit. Este pequeño cambio de agenda ha pillado con el pie cambiado a más de un mantenedor que intentaba colar la última petición de integración apurando plazos.

Una ventana de integración atípica pero con un patrón «normal»

Torvalds ha explicado que esta ventana de integración ha sido ligeramente diferente a lo habitual por dos motivos: varios mantenedores han estado viajando por el mantenedor summit y, al mismo tiempo, se han incluido varias series de cambios dedicados a ampliar el uso de la infraestructura automática de limpieza del compilador. Este trabajo se ha notado en diferentes subsistemas, aunque la capa VFS destaca por la magnitud de sus conversiones.

En el apartado de Rust dentro del kernel, el proyecto empieza a salir de la fase puramente preparatoria. Hasta ahora predominaban los cimientos y la infraestructura, pero con Linux 6.19-rc1 ya se empiezan a ver controladores y subsistemas escritos realmente en Rust tomando forma, algo que, si se consolida, podría ir ganando peso en versiones futuras.

En cifras gruesas, alrededor de la mitad de los parches de este rc1 corresponden a drivers: destacan los de GPU, redes, sonido y media, aunque hay cambios repartidos por prácticamente todos los rincones del kernel. El resto se reparte entre actualizaciones de arquitecturas, herramientas, documentación, soporte Rust y retoques en componentes internos como la memoria (mm), el planificador, la pila de red y otras piezas troncales.

Linux 6.19-rc1 frente a 6.18: primeras pruebas de rendimiento

Mientras se cerraba la ventana de integración, comenzaron las primeras comparativas entre Linux 6.18 estable y el estado Git de 6.19 previo a rc1. Los ensayos se han realizado con el mismo archivo de configuración del kernel y aceptando únicamente los nuevos valores por defecto que propone la rama 6.19, sin más cambios en el sistema operativo.

En un primer escenario se usó un servidor AMD EPYC 9655P monoprocesador con 96 núcleos y 192 hilos, montado sobre una placa Supermicro H13SSL-N y ejecutando Ubuntu 25.10. El objetivo era medir el impacto directo del salto de versión de kernel sobre un entorno servidor moderno con un hardware que empieza a ser habitual en centros de datos europeos.

Los resultados iniciales muestran un panorama mixto: algunas pruebas apuntan a ligeras mejoras de rendimiento, mientras que otras evidencian regresiones notables para tratarse de un estado tan temprano del desarrollo. Esto no es raro en un pre-rc1, pero sí sirve de aviso a administradores y usuarios avanzados que se planteen desplegar este kernel en entornos sensibles.

Regresiones tempranas en el planificador y la pila de red

Las pruebas de estrés con Stress-NG han destapado retrocesos importantes en determinados escenarios. En concreto, se han observado grandes regresiones en el rendimiento del planificador mixto y en las operaciones de sockets frente a Linux 6.18 estable. Estos comportamientos, medidos con microbenchmarks, son de los más llamativos dentro del conjunto de tests realizados.

En la misma línea, al ejecutar la herramienta de red Microsoft Ethr en localhost también se ha visto a Linux 6.19 en clara desventaja respecto a 6.18, con un rendimiento de red inferior en este estado inicial del código. Es un aviso temprano de que ciertos ajustes en el planificador y la pila de red podrían necesitar revisión antes de la versión estable.

No todo son malas noticias: dentro de los propios tests de Stress-NG se han detectado mejoras en el manejo de semáforos, así como un pequeño incremento en el rendimiento general medido como throughput global. También se ha apreciado un mejor comportamiento en el cambio de contexto entre procesos, un aspecto que suele beneficiar a sistemas con alta concurrencia.

Otros benchmarks como Hackbench, centrado en el planificador, han mostrado mejoras modestas en Linux 6.19 respecto a 6.18. Sin embargo, cuando se pasa de pruebas sintéticas a cargas de trabajo más cercanas al mundo real, la tendencia general en esta fase del desarrollo es que Linux 6.19 Git se comporte igual o ligeramente peor que la versión estable anterior.

Impacto en sistemas de escritorio y estabilidad del sistema de archivos en Linux 6.19-rc1

Al margen de los servidores, también se ha probado Linux 6.19 Git en un escritorio con CPU AMD Ryzen. En este caso, los resultados han sido más preocupantes en términos de estabilidad: durante las pruebas aparecieron errores de sistema de ficheros que no se reproducían al volver a Linux 6.18 estable sobre la misma máquina.

Este tipo de fallos en el escritorio, aunque todavía en investigación, refuerzan la idea de que 6.19-rc1 y las versiones de Git previas no están listas para un uso generalizado fuera de entornos de prueba o de desarrollo. De cara a usuarios finales en España o Europa que valoren la estabilidad por encima de todo, la recomendación razonable sigue siendo permanecer en la rama LTS o estable hasta que estos problemas estén acotados y corregidos.

Está previsto que, una vez pasada la agitación de la ventana de integración y con el código más estabilizado, se realicen nuevas baterías de pruebas en más hardware, incluyendo la posibilidad de hacer «bisecciones» del kernel para localizar con precisión los parches responsables de las regresiones más serias.

Nuevos drivers de reloj en tiempo real (RTC) para Apple y NVIDIA

Entre las fusiones destacadas que han entrado en Linux 6.19 antes del cierre de la ventana se encuentra el conjunto de cambios del subsistema de relojes en tiempo real (RTC). Aunque normalmente es un área algo discreta, en esta ocasión incorpora novedades llamativas para usuarios de hardware reciente.

Por un lado, se ha añadido el driver «rtc-macsmc» para Apple Silicon, desarrollado originalmente por Hector Martin durante su etapa al frente del proyecto Asahi Linux. Este controlador da soporte al RTC integrado en el circuito de gestión de energía (PMU) de Apple, que a su vez está abstraído por el System Management Controller (SMC). El contador de tiempo real se accede a través del SMC, y este nuevo driver brinda a Linux la capacidad de gestionar adecuadamente el reloj de los Mac con arquitectura ARM de Apple, similar a otros parches de soporte.

Por otro lado, se estrena el driver RTC «NVVRS» para plataformas NVIDIA Tegra en ARM64. Este controlador implementa el soporte para el reloj en tiempo real de la especificación de regulador de voltaje (Voltage Regulator Specification, VRS) de NVIDIA, utilizado en dispositivos como Jetson AGX Orin, IGX Orin, Jetson Orin NX y Jetson Orin Nano. Entre sus funciones se incluyen la gestión del tiempo del sistema, la conservación de la hora entre reinicios y la activación del equipo desde estados de suspensión o apagado.

El lote de cambios del RTC en Linux 6.19 se completa con un nuevo driver de reloj en tiempo real para Andes ATCRTC100, ampliando el abanico de plataformas soportadas. Para integradores y fabricantes europeos que trabajan con soluciones embebidas o con dispositivos Jetson desplegados en industria, robótica o IA en el borde, estas mejoras facilitan configuraciones más robustas y alineadas con el hardware actual.

LoongArch da el salto a 32 bits con LoongArch32

En el apartado de arquitecturas, Linux 6.19 incorpora avances significativos para LoongArch, el diseño de CPU doméstico chino inspirado en MIPS y RISC-V. Hasta ahora, el soporte en el kernel se centraba en LoongArch64 (64 bits), pero con esta versión comienza a tomar forma la base para LoongArch32, la variante de 32 bits.

A diferencia de la transición tradicional del mercado —donde se ha pasado de 32 a 64 bits—, Loongson está dando el paso inverso: de 64 a 32 bits. En Linux 6.19 se empiezan a conectar las piezas del port para LoongArch32 en el kernel, si bien el soporte de compilación aún no se activa por defecto porque faltan ajustes en algunos drivers y es necesario que el soporte correspondiente en la herramienta GNU (binutils, GCC, etc.) termine de asentarse upstream.

LoongArch32 contempla dos variantes principales: una versión reducida de 32 bits (LA32R) y una versión estándar (LA32 / LA32S). En paralelo, ya han empezado a aterrizar parches en GCC para habilitar el objetivo LoongArch32 de cara a GCC 16, cuya publicación se espera para principios de 2026. Además, continúa el trabajo en el resto de la cadena de herramientas, incluyendo depuradores y otros componentes asociados a los ABI de LoongArch32.

También existen parches para emular LoongArch32 sobre hardware LoongArch64, aunque de momento no se han hecho públicas referencias concretas a procesadores únicamente LA32. Este movimiento se interpreta como un paso estratégico para ofrecer más flexibilidad en gamas de producto y escenarios embebidos, y posiciona a Linux 6.19 como una pieza clave en la maduración de esta arquitectura alternativa.

Linux 6.19-rc1 ya dispoible para probar

Con todo este conjunto de cambios, Linux 6.19-rc1 se presenta como una versión candidata cargada de novedades: desde ese empuje a Rust y las mejoras en drivers, hasta los nuevos controladores RTC para Apple y NVIDIA, el avance en LoongArch32 y las pruebas de rendimiento en hardware AMD EPYC de última generación. Pese a las regresiones detectadas en planificación y red, y a ciertos problemas de estabilidad en escritorio, el ciclo que se abre ahora servirá para pulir estos aspectos antes del lanzamiento estable previsto para principios de febrero, momento en el que administradores y usuarios en España y Europa podrán valorar con más garantías el salto a este nuevo kernel.