Linux 7.3 todavía está en desarrollo, pero las mejoras que están entrando durante su ventana de integración dibujan una versión especialmente interesante para almacenamiento, latencia, memoria y procesadores híbridos. Btrfs, EXT4, el planificador de CPU, zsmalloc, KSM y el código SMP reciben cambios que en determinados escenarios muestran mejoras desde un 10 % hasta varios múltiplos de rendimiento, aunque conviene separar los resultados de laboratorio de lo que verá cada usuario cuando llegue la versión estable.
Las claves de Linux 7.3 en 20 segundos
- Btrfs mejora su E/S directa y cambia su caché de espacio libre predeterminada hacia la implementación v2.
- EXT4 y XFS ganan rendimiento con pequeñas operaciones directas sobre SSD PCIe 5.0.
- El planificador recibe cambios orientados a reducir latencias y mejorar los tiempos de cuadro bajo carga.
- zsmalloc y KSM reducen bloqueos que podían penalizar especialmente sistemas con mucha presión de memoria.
- Intel prepara una mejor distribución de cargas entre P-cores, E-cores y núcleos de bajo consumo.
Linux 7.2 fue publicado el 16 de agosto de 2026 y Linus Torvalds abrió inmediatamente después la ventana de integración de Linux 7.3. Por tanto, muchas de las novedades que se comentan actualmente ya están propuestas o integrándose, pero la versión estable todavía no está disponible y algunos cambios podrían modificarse o incluso retirarse si aparecen regresiones durante las versiones RC.
Aun con esa cautela, el patrón es bastante claro. Linux 7.3 no parece una versión dominada por una única función espectacular, sino por eliminación de cuellos de botella que empiezan a resultar visibles con almacenamiento muy rápido, muchos núcleos y cargas cada vez más sensibles a la latencia.
Btrfs mejora precisamente donde más le penalizaba la complejidad
Btrfs acumula algunas de las novedades de rendimiento más interesantes del ciclo.
Una de ellas afecta a las operaciones O_DIRECT. Desde Linux 6.14, Btrfs podía hacer que determinadas escrituras directas con checksums terminaran utilizando E/S almacenada en búfer para evitar inconsistencias si una aplicación modificaba el buffer mientras se calculaba el checksum.
Linux 7.3 introduce un bounce buffer para estos casos. La documentación oficial de Btrfs señala que este mecanismo puede alcanzar aproximadamente el 95 % del rendimiento de una operación direct I/O realmente zero-copy, sin tener que recurrir al camino de E/S almacenada en caché.
La actualización también modifica la gestión interna de extent buffers y elimina esperas innecesarias en determinados escenarios de registro concurrente.
Se han difundido cifras de mejoras de 3 a 5 veces en algunos benchmarks de Btrfs, pero es importante no interpretarlas como que Linux 7.3 vaya a hacer que cualquier volumen Btrfs funcione cinco veces más rápido.
Esos resultados corresponden a caminos concretos del código y cargas específicas. La mejora que perciba un usuario dependerá de operaciones realizadas, dispositivo, concurrencia, configuración y tamaño del sistema de archivos.
Otro cambio relevante es la caché de espacio libre.
Btrfs dispone desde hace años de dos implementaciones: space_cache=v1 y free-space tree o v2. La primera ha sido históricamente la opción predeterminada, mientras que v2 utiliza un B-tree adicional para registrar el espacio disponible y escala mejor en sistemas de archivos grandes. La documentación ya advertía de que v1 podía degradarse considerablemente en volúmenes de varios terabytes y determinadas cargas.
El trabajo para Linux 7.3 pasa por dejar atrás v1 como elección predeterminada y favorecer space cache v2, aunque las instalaciones existentes requieren tener en cuenta el estado actual de su sistema de archivos.
Para servidores, NAS y estaciones con volúmenes Btrfs grandes, probablemente sea una de las novedades más relevantes de toda la versión.
EXT4 y XFS empiezan a encontrarse con un problema inesperado: el kernel es demasiado lento para el NVMe
El almacenamiento actual permite explicar perfectamente por qué siguen siendo necesarias estas optimizaciones.
En una prueba con lecturas aleatorias de 4 KB sobre un SSD PCIe Gen5 NVMe, el dispositivo bruto alcanzaba alrededor de 3,2 millones de IOPS utilizando io_uring en modo polling.
Al ejecutar prácticamente la misma carga mediante EXT4 o XFS, el rendimiento caía hasta unos 1,92 millones de IOPS.
El problema ya no estaba principalmente en el SSD.
Estaba en el software.
El análisis mostró una cantidad importante de tiempo de CPU consumida por __iomap_dio_rw(), el iterador de iomap, asignaciones de memoria y operaciones relacionadas con la finalización de la E/S.
La solución incorporada para Linux 7.3 crea un camino simplificado para pequeñas operaciones directas que cumplen determinadas condiciones.
El resultado publicado aumenta EXT4 desde 1,92 hasta 2,19 millones de IOPS en la prueba original, aproximadamente un 14 %. Las pruebas con fio mostraron mejoras cercanas al 4 % con libaio, alrededor del 5 % con io_uring y de hasta el 10 % con io_uring en modo polling y colas profundas, tanto en EXT4 como en XFS.
Es un buen ejemplo de cómo cambia la optimización del kernel.
Durante años buena parte del trabajo consistió en intentar ocultar las enormes latencias de los discos mecánicos. Con un NVMe de última generación, varios microsegundos de software empiezan a convertirse en el cuello de botella.
EXT4 también continúa recibiendo trabajo en su asignador multibloque y en las rutas relacionadas con fallocate(), aunque no conviene mezclar todos estos cambios con el salto de 1,92 a 2,19 millones de IOPS: esa cifra concreta procede del nuevo camino simplificado de iomap para pequeñas lecturas directas.
El scheduler cambia para reducir tirones bajo carga
Otra de las áreas más interesantes es el planificador.
Una serie conocida como “flatten the pick” busca modificar cómo trabaja EEVDF cuando existen jerarquías de cgroups.
El problema está en que las estructuras intermedias utilizadas para representar grupos de tareas pueden ocultar temporalmente qué procesos están realmente preparados para ejecutarse. Esto puede aumentar latencias y costes de planificación.
El nuevo enfoque mantiene la jerarquía de cgroups, pero utiliza una cola EEVDF más plana para seleccionar las tareas.
Las pruebas mostradas durante el desarrollo utilizaron un equipo bastante antiguo con Intel Sandy Bridge y una GPU AMD Radeon Polaris, precisamente para comprobar escenarios donde cada milisegundo adicional tiene un efecto visible.
Los resultados apuntan a mejores FPS y, especialmente, tiempos de cuadro más estables bajo ruido generado por cgroups.
De ahí viene la referencia a mejoras para hardware “potato”.
No significa que Linux 7.3 vaya a multiplicar los FPS de cualquier equipo antiguo. El efecto es más específico: cuando existen cargas competidoras y el scheduler introduce retrasos, reducir esas interferencias puede disminuir los picos de frametime.
Esto importa más de lo que parece para juegos.
Un sistema puede mantener una media de 60 FPS y ofrecer una sensación desagradable si aparecen fotogramas que tardan mucho más que los demás. Por eso mejorar la regularidad puede resultar más apreciable que aumentar ligeramente la media.
zsmalloc gana hasta 1,83 veces en Raspberry Pi bajo concurrencia
La gestión de memoria también recibe optimizaciones bastante concretas.
zsmalloc es un asignador utilizado especialmente por tecnologías de memoria comprimida como zram.
Un conjunto de cambios busca eliminar contención dentro de zs_free(). En sistemas de 64 bits, el índice de la clase puede codificarse directamente dentro del valor del objeto, evitando tener que adquirir determinados bloqueos globales para localizar su clase.
Las pruebas son especialmente interesantes en hardware pequeño.
En una Raspberry Pi 4B con cuatro Cortex-A72, una prueba concurrente con cuatro procesos bajó de 202,9 ms a 110,6 ms, equivalente a aproximadamente 1,83 veces más rendimiento.
Con dos procesos el aumento fue de 1,42 veces.
En un sistema x86 con Intel Core i7-12700 y 16 procesos concurrentes, las mejoras rondaron entre 1,39 y 1,40 veces para esas cargas multihilo.
En ejecución con un único proceso la diferencia fue mucho menor.
Eso ayuda a interpretar correctamente los números: la optimización ataca principalmente la contención entre procesos, así que su efecto aumenta cuando varios núcleos intentan liberar memoria comprimida simultáneamente.
Para sistemas que utilizan zram intensivamente, incluidos pequeños dispositivos ARM, puede tener un impacto bastante interesante.
KSM reduce bloqueos de más de medio segundo a menos de 2 ms
Otro cambio de memoria tiene cifras todavía más llamativas.
Kernel Same-page Merging (KSM) permite localizar páginas de memoria con contenidos idénticos y compartirlas. Es una técnica especialmente útil en virtualización y entornos con numerosas cargas similares.
El problema aparecía durante determinadas operaciones de reverse mapping.
En una prueba con 20.000 VMA compartiendo un mismo anon_vma, una ruta ineficiente de KSM podía mantener un bloqueo durante más de 500 ms.
Las cifras publicadas por los desarrolladores muestran un peor caso de 705 ms antes del cambio y 1,67 ms después, con una media máxima medida de 1,44 ms.
Eso supone una mejora de varios cientos de veces en ese escenario concreto.
Lo importante no es únicamente KSM.
Ese mismo bloqueo también puede ser necesario para page faults, recuperación de memoria, migración, compactación, mlock, salida de procesos y contabilidad de cgroups.
Mantenerlo durante centenares de milisegundos puede provocar picos de latencia, reducir throughput e incluso generar timeouts en contenedores.
Aquí la mejora de Linux 7.3 no busca aumentar una puntuación de benchmark, sino eliminar pausas extremadamente largas en situaciones patológicas pero posibles.
La latencia SMP cae de unos 17 ms a 1,5 ms
Probablemente otra de las optimizaciones más interesantes para servidores esté en el código SMP.
Determinadas llamadas entre procesadores utilizan IPI, Inter-Processor Interrupts, para pedir que otros núcleos ejecuten una operación.
Hasta ahora algunas funciones mantenían deshabilitada la preempción mientras esperaban que todos los procesadores remotos terminaran su trabajo.
Si alguno tardaba en responder, podía generarse un pico importante de latencia.
Ingenieros de ByteDance trabajaron en permitir nuevamente la preempción durante esa espera.
Según los datos asociados al cambio, la latencia P99 para tareas de alta prioridad medida en producción pasó de aproximadamente 17 ms a 1,5 ms, una reducción cercana al 90 %.
Las cargas sensibles a latencia como DPDK pueden beneficiarse especialmente.
También resulta relevante en servidores con muchos procesadores donde operaciones relacionadas con TLB, liberación de memoria o terminación de procesos pueden acabar generando muchas llamadas entre CPU.
De nuevo, no significa que cualquier aplicación sea ahora diez veces más rápida. La mejora consiste en reducir colas largas de latencia cuando se produce precisamente ese patrón de espera SMP.
Alder Lake, Lunar Lake y Panther Lake mejoran el reparto entre sus diferentes núcleos
La arquitectura híbrida de Intel continúa planteando retos interesantes para Linux.
Los procesadores modernos pueden combinar P-cores orientados a rendimiento, E-cores eficientes e incluso núcleos de muy bajo consumo, y el scheduler debe decidir constantemente dónde ejecutar cada tarea.
Linux dispone desde 2021 de planificación consciente de clústeres para agrupar núcleos que comparten cachés u otros recursos intermedios.
El problema es que este enfoque no siempre se adapta bien a los diseños híbridos.
Intel ha preparado cambios para Linux 7.3 destinados a mejorar este cluster-aware load balancing, especialmente cuando existe una mezcla de cargas y aparecen nuevas tareas mientras otros núcleos están ocupados.
Los cambios son relevantes para familias como Alder Lake, Lunar Lake y las nuevas generaciones Panther Lake, aunque el impacto real debería analizarse mediante pruebas una vez que el kernel 7.3 esté más cerca de su versión definitiva.
No necesariamente aparecerán grandes diferencias en benchmarks completamente monohilo o capaces de saturar todos los núcleos. El beneficio potencial está más bien en cargas mixtas, justo el escenario habitual de un ordenador real.
Linux 7.3 parece diseñado para eliminar límites que antes no importaban
Hay un elemento común detrás de buena parte de estas novedades.
El hardware está obligando al kernel a eliminar costes que hace unos años resultaban relativamente insignificantes.
Un NVMe PCIe 5.0 puede hacer que una capa de software genérica limite millones de IOPS.
Decenas de núcleos hacen que mantener deshabilitada la preempción mientras se espera una IPI se convierta en un problema de latencia.
La memoria comprimida funciona bien hasta que numerosos procesadores empiezan a competir por el mismo bloqueo.
Los procesadores híbridos funcionan correctamente hasta que el scheduler tiene que elegir entre núcleos con capacidades y consumos muy diferentes.
Y el mismo fenómeno aparece en Btrfs, donde estructuras diseñadas años atrás empiezan a necesitar cambios a medida que los sistemas de archivos y las cargas aumentan de escala.
Linux 7.3 todavía está dentro de su ciclo de desarrollo, así que será necesario esperar a las versiones RC y a los benchmarks independientes antes de declarar cuánto mejora realmente cada escritorio o servidor.
Pero, por los cambios que están entrando, todo apunta a una versión especialmente centrada en reducir latencias, mejorar concurrencia y extraer más rendimiento del hardware moderno sin exigir cambios a las aplicaciones.
Preguntas frecuentes
¿Linux 7.3 ya está disponible?
No como versión estable. Linux 7.2 se publicó el 16/08/2026 y a continuación comenzó la ventana de integración de Linux 7.3. Todavía debe atravesar el ciclo de versiones RC antes de su lanzamiento definitivo.
¿Btrfs será entre tres y cinco veces más rápido con Linux 7.3?
No en todas las cargas. Se han observado mejoras de ese orden en escenarios concretos relacionados con determinados caminos internos. Otras operaciones tendrán ganancias mucho menores.
¿Qué mejora Linux 7.3 con SSD PCIe 5.0?
El nuevo camino simplificado para pequeñas operaciones directas reduce el coste de iomap. En una prueba sobre EXT4, las lecturas aleatorias de 4 KB mediante io_uring pasaron de 1,92 a 2,19 millones de IOPS.
¿Linux 7.3 mejorará los juegos?
El nuevo trabajo sobre EEVDF y cgroups puede reducir latencias y mejorar la estabilidad de los tiempos de cuadro cuando existen cargas competidoras. Los primeros resultados son prometedores, especialmente sobre hardware antiguo, pero no implican una mejora uniforme de FPS para todos los equipos.
