Linux 7.2: qué cambia de verdad en un servidor (y qué kernel corre en realidad tu clúster)

Un vistazo en 30 segundos

• Linux 7.2 se publicó el domingo 16 de agosto de 2026. No es una versión longterm: las de soporte largo hoy son 6.18, 6.12, 6.6, 6.1, 5.15 y 5.10.
• Llega el Cache Aware Scheduling, que intenta mantener juntos en el mismo dominio de caché LLC los hilos que comparten datos.
• Btrfs activa los large folios por defecto (eran experimentales desde 6.17) y estrena folios enormes de hasta 2 MiB como opción experimental.
• Las cifras que circulan (15 % en escrituras secuenciales, ~59 % en E/S directa) son las que reportan los propios parches en su banco de pruebas, no una promesa para tu cabina.
• MGLRU limpia su bucle de recuperación y el manejo de páginas sucias: hasta ~30 % de mejora en cargas tipo MongoDB con YCSB, según el resumen upstream.
• KVM suma el juego combinado MBEC (Intel) y GMET (AMD), actualización del módulo TDX en caliente y contadores de rendimiento mediados para AMD.
• Aquí viene lo interesante para quien va con Proxmox: Proxmox VE 9.2 y Proxmox Backup Server 4.2 ya llevan kernel 7.0 y los parches de MBEC y GMET los integró Proxmox por su cuenta en mayo.
• El planificador «justo» de GPU se revirtió a última hora por una regresión seria y 7.2 sale con FIFO. Es el recordatorio de cómo se cierra de verdad un ciclo de kernel.

---

El 16 de agosto Linus Torvalds etiquetó Linux 7.2 y arrancó el ciclo siguiente. La lista de novedades da para muchos titulares, la mayoría sobre HDMI 2.1 en tarjetas Radeon, que es justo lo que menos te afecta si lo que administras son nodos sin entorno gráfico.

Lo que sí cambia el comportamiento de un servidor está en sitios menos vistosos: cómo reparte el planificador los hilos entre cachés, cómo recupera memoria el kernel cuando empieza a apretar la RAM, con qué tamaño escribe un sistema de archivos y qué le puede pedir un hipervisor al procesador. Vamos por ahí, y al final nos hacemos la pregunta que casi nadie hace en estos repasos: qué kernel corre realmente en tus máquinas.

El planificador empieza a mirar dónde está la caché

La novedad con más trabajo detrás es el Cache Aware Scheduling, más de un año de desarrollo empujado sobre todo desde Intel.

El problema que resuelve lleva ahí desde que los procesadores de servidor pasaron de tener una caché de último nivel compartida a tener varias. En una máquina con dos zócalos y varios chiplets por zócalo, encontrar un núcleo libre es fácil; lo difícil es saber si vale la pena llevar hasta él un hilo que estaba trabajando sobre datos que ahora viven en otra LLC. Si el traslado obliga a recuperar todo eso desde memoria, el núcleo libre sale caro.

Lo que hace 7.2 es equilibrar la carga teniendo en cuenta la localidad: intenta colocar los hilos de un mismo proceso, que suelen compartir datos, dentro del mismo dominio de caché. Menos rebote de líneas de caché, menos fallos, mejor acceso a datos.

No se aplica a lo loco. El kernel mira las características de la carga y la capacidad efectiva de la caché antes de decidir, porque agrupar un proceso monohilo no compensa el coste de seguirlo, y concentrar una carga cuya huella de memoria desborda la LLC tampoco arregla nada.

Traducido a una plataforma de virtualización: puede notarse en nodos con muchos núcleos y topologías de caché partidas, sobre todo con VM de varias vCPU que trabajan sobre el mismo conjunto de datos. Puede. Este tipo de cambios se miden, no se suponen, y para eso hace falta tener monitorización con histórico desde antes de tocar nada.

Memoria: MGLRU afinado y la tabla de swap adelgazada

MGLRU es el mecanismo que decide qué páginas conservar y cuáles soltar cuando la RAM escasea. En 7.2 recibe una limpieza de su bucle de recuperación y del manejo de páginas sucias pendientes de escritura, que era donde se comportaba peor que el LRU clásico: podía tardar más en arrancar el writeback y quedarse dando vueltas sobre páginas que no podía liberar todavía.

El resumen upstream habla de hasta un 30 % de mejora en cargas como MongoDB con YCSB, una caída fuerte de los refaults de fichero, ninguna regresión en el resto de pruebas habituales, menos líneas de código y menos OOM inesperados. Esa última parte es la que a mí me parece más valiosa en producción: un kernel que mata menos procesos por sorpresa vale más que un porcentaje en un benchmark.

Va acompañado de la fase IV del trabajo de swap tables, que unifica cómo se reservan y contabilizan las páginas de swap anónimas y de shmem y consolida los metadatos. El resultado es que la sobrecarga estática se queda casi en cero: montar un dispositivo de swap de 1 TB ahorra unos 512 MB de memoria que antes se iban en estructuras internas.

Todo esto se nota poco mientras vas sobrado de RAM y mucho en cuanto empiezas a apretar la densidad de un nodo, que es justo el momento en el que se paga haber elegido bien entre contenedor y máquina virtual.

Btrfs corre más, pero mira antes qué sistema de archivos usas de verdad

Btrfs se lleva buena parte del trabajo de sistemas de archivos, y aquí conviene leer las cifras con lupa.

Los large folios pasan a estar activos por defecto y sin limitaciones de funcionalidad; eran experimentales desde 6.17. Un folio es un conjunto de páginas de memoria tratado como una unidad, así que la idea es sencilla: mover 2 MiB de una vez sale más barato que hacer el mismo trabajo página a página. Encima llegan los huge folios de hasta 2 MiB para páginas de 4K, esta vez sí marcados como experimentales.

Las dos cifras que están circulando por todas partes vienen de commits concretos:

• limitar el tamaño de los bios que se envían desde el writeback, con un 15 % de mejora reportada en escrituras secuenciales;
• dejar de forzar que las escrituras de E/S directa vayan en serie, herencia de una migración de API que ya no hacía falta, con cerca de un 59 % más de throughput en E/S directa.

Son medidas del escenario de prueba de cada parche. Sirven para saber por dónde va el trabajo, no para prometerle a nadie un 59 % en su cabina.

Y ahora el matiz que casi ningún repaso de kernel incluye: si administras Proxmox VE, es bastante probable que nada de esto te toque. La integración de Btrfs en Proxmox VE sigue siendo, según la documentación oficial, una technology preview. Lo normal ahí es ZFS o LVM-thin, y OpenZFS es un módulo fuera del árbol del kernel, con su propio ciclo de versiones (Proxmox VE 9.2 va con ZFS 2.4), así que los folios de Btrfs no le hacen ni cosquillas a tu pool. Si lo tuyo es dedup y compresión sobre ZFS, las novedades que te importan salen de otro repositorio.

Del resto de sistemas de archivos, dos apuntes útiles: ext4 se lleva una reescritura importante del mecanismo de fast commit para evitar contención de bloqueos e interbloqueos, y XFS retira por fin el aviso de experimental de su asignador por zonas.

NFS, SMB y red

El servidor NFS del kernel sube el tamaño de bloque de lectura y escritura por defecto a 4 MB en equipos con al menos 16 GB de RAM, con lo que baja la sobrecarga por RPC en redes rápidas. Las máquinas con menos memoria mantienen el valor calculado de antes, y sigue siendo ajustable en /proc/fs/nfsd/max_block_size. Viene acompañado de delegaciones de directorio en NFSD y de revocación automática del estado NFSv4 al desmontar el sistema de archivos.

Por el lado SMB, ksmbd valida los contextos de lease en SMB2 y ya puede comprimir las respuestas de lectura SMB2.

En red hay tres cosas que merecen mención:

• PPPoE estrena GRO y GSO, agrupando y segmentando tráfico dentro de la pila en lugar de procesar paquete a paquete.
• TCP-AO se reimplementa sobre la biblioteca criptográfica del kernel. Ojo con esto, porque se está contando como si TCP-AO fuese nuevo: la autenticación de segmentos TCP del RFC 5925 lleva años en el kernel. Lo de 7.2 es fontanería interna, no una función que aparezca de golpe en tus routers.
• MPTCP sigue puliendo el anuncio de direcciones IPv6 con puerto, y hay trabajo fino en IPv6 para quitar el rtnl_lock de la configuración de encaminamiento multicast.

Nada de esto cambia el día a día de una red de centro de datos, pero si estás montando overlays EVPN/VXLAN conviene saber por dónde se mueve la pila.

KVM: control de ejecución más fino y TDX actualizable en caliente

La virtualización se lleva un bloque grande de cambios.

El más citado es el parche combinado de MBEC y GMET. Ambos permiten un control más fino de los permisos de ejecución dentro de una VM, con distinta separación entre modo supervisor y modo usuario: MBEC (Intel) aporta bits separados de supervisor y usuario en las entradas de página, mientras que GMET (AMD) no distingue ejecución solo-supervisor. Sirven para que el hipervisor pueda controlar qué se ejecuta dentro del invitado con más precisión, que es la base de bastantes defensas contra ataques al kernel del invitado.

Con TDX de Intel llega algo más concreto que «avances»: soporte de actualización del módulo TDX en tiempo de ejecución. Poder actualizar la pieza de firmware que sostiene los dominios de confianza sin parar el host cambia bastante la conversación operativa alrededor de la computación confidencial.

Se suman los contadores de rendimiento mediados con los bits Host-Only y Guest-Only de AMD, la virtualización del «deshabilitar CPUID en modo usuario» de AMD y una extensión de KVM_HC_MAP_GPA_RANGE que ya admite reintentos.

Recordatorio de siempre: que algo entre en el kernel no significa que puedas usarlo mañana. Entre el parche y tu consola hay generación de procesador, firmware, microcódigo, QEMU, libvirt y la configuración del host. Con TDX intervienen tantas capas que la pregunta útil no es «¿está en 7.2?» sino «¿lo soporta el conjunto completo de mi plataforma?».

Lo que se cayó del camión antes de salir

La parte menos vistosa de un ciclo de kernel, y la que más dice sobre cómo se trabaja upstream, son las reversiones de última hora.

El subsistema DRM traía un planificador de trabajos de GPU nuevo, inspirado en el viejo CFS, que iba a sustituir al FIFO de siempre como política por defecto. Ya estaba dentro cuando llegó un informe de regresión serio: en una Radeon RX 9070 XT, un juego bajo Proton con la GPU a tope se desplomaba a unos 10 fps o se congelaba, y la sesión de KDE Plasma sobre Wayland podía quedarse bloqueada hasta el punto de necesitar reinicio. Tvrtko Ursulin, de Igalia, que lideró el trabajo, decidió revertir la política. Linux 7.2 sale con FIFO como política por defecto y el planificador «justo» queda para 7.3, con parches ya publicados para arreglar la regresión.

También se dieron marcha atrás cambios en I2C DesignWare (uno de ellos podía dejar tocado el touchpad de algunos ThinkPad), en el controlador wifi mt76 y en componentes de Qualcomm.

Lo que no es noticia acaba siendo la lección: las últimas semanas de un ciclo estable consisten tanto en retirar cosas como en meterlas.

AMDGPU y HDMI 2.1: mucho titular, poco servidor

AMD estrena en 7.2 la base de HDMI 2.1 FRL (Fixed Rate Link) y el trabajo asociado de DSC sobre FRL. FRL supera el límite de ancho de banda del TMDS que HDMI usaba antes, y es lo que hace falta para ciertas combinaciones de resolución y refresco.

Es una buena noticia para estaciones de trabajo Linux con Radeon conectadas a monitores o televisores modernos, y conviene no leerla como «HDMI 2.1 ya funciona del todo»: el soporte de VRR y FreeSync sobre FRL siguió evolucionando después. En un nodo de virtualización esto es irrelevante salvo que hagas passthrough de GPU, y ahí lo que decide es el driver del invitado, no el del host.

La pregunta que no hace nadie: ¿qué kernel corre tu clúster?

Aquí es donde estos repasos suelen terminar y donde debería empezar la conversación.

Que kernel.org anuncie 7.2 no significa que vayas a verlo. Lo dicen ellos mejor que nadie: si al ejecutar uname -r ves cualquier cosa detrás del guion, estás usando un kernel de distribución, no el de kernel.org. En un nodo de Proxmox sale algo como 7.0.x-y-pve, y esa -pve significa que llevas cientos de parches, reversiones y backports por encima del mainline.

Fíjate en el detalle: Proxmox VE 9.2 lleva desde mayo el kernel 7.0 y, según su propio changelog, integró los parches de MBEC y GMET para ese kernel. O sea, la novedad estrella de KVM en 7.2 la tiene un usuario de Proxmox desde hace tres meses, por backport. Al revés pasa lo mismo: si vas con Debian 13 o RHEL 10, tu kernel es un 6.12 con soporte hasta finales de 2028 y las mejoras de MGLRU de 7.2 no las vas a ver, salvo que alguien las retroporte.

Ese es el trabajo real de una distribución de servidor, y es la razón por la que perseguir mainline en producción rara vez sale a cuenta.

Actualizar el kernel no es «apt upgrade y ya»

Si necesitas argumentos para no correr, el propio changelog de Proxmox VE 9.2 es una colección estupenda de motivos, todos de los últimos meses:

• hubo que revertir cambios de TCP del kernel 6.17 porque provocaban atascos en las conexiones de copia y sincronización de Proxmox Backup Server;
• LINSTOR y DRBD tuvieron problemas de compatibilidad con 6.17;
• algunos Dell PowerEdge no arrancaban bien con 6.17;
• las CPU AMD Zen 5 con firmware antiguo se quedaron sin la instrucción RDSEED a partir de 6.17.9, hasta el punto de que el instalador avisa;
• se retroportaron arreglos para caídas del kernel con el driver mpt3sas, para una regresión de USB HID que afectaba a la comunicación con SAI de APC y para pánicos con ZFS cuando un cgroup se pasaba de su límite de memoria.

Ninguna de esas cosas sale en las notas de prensa de un kernel nuevo. Todas te tiran un nodo.

Hay dos particularidades más de una plataforma de virtualización que conviene tener presentes. La primera es que los contenedores LXC comparten el kernel del host: cuando actualizas el kernel de un nodo, actualizas de golpe el kernel de todos sus contenedores, mientras que las VM siguen con el suyo. La segunda es que un cambio de kernel casi siempre implica reinicio, así que el procedimiento no es una ventana de mantenimiento sino una actualización nodo a nodo con migración en vivo y comprobación de quórum entre paso y paso.

Que todo esto duela es justo lo que ha empujado el trabajo de KHO y LUO, el mecanismo del kernel para saltar de una versión a otra conservando memoria, que ya está dentro y del que 7.2 trae más piezas. Lo contamos aparte, con lo que sirve hoy y lo que no: cambiar de kernel sin apagar las cargas.

Y luego está la otra cara: quedarse quieto tampoco es gratis. Las vulnerabilidades del kernel se arreglan en las ramas soportadas, y ahí es donde una CVE como la de bad_epoll marca la diferencia entre tener un parche disponible o estar fuera de soporte. Correr detrás de mainline es mala idea; quedarse en una rama que ya nadie mantiene es peor.

Cómo lo miramos nosotros

En las plataformas que gestionamos, la versión del kernel no la decide una nota de prensa. La decide el fabricante de la distribución que sostiene el clúster, y por encima va lo que ya está firmado: ventanas de servicio, objetivos de disponibilidad y qué se puede reiniciar y cuándo.

Nuestro criterio con una versión como 7.2 es de manual: se sigue de cerca, se anota qué mejoras interesan a qué carga y se espera a que lleguen empaquetadas y probadas por la distribución. Si algo urge de verdad, se prueba en un nodo fuera de producción con la carga real encima y se mide antes y después, no con un benchmark sintético.

Si estás con un parque de Proxmox y no tienes claro en qué kernel está cada nodo ni cuándo tocará el siguiente salto, échale un ojo a nuestras páginas de cloud privado con Proxmox y de servicios gestionados. Y si prefieres que lo revisemos contigo, cuéntanos cómo lo tienes montado y te decimos qué actualizaríamos, en qué orden y qué dejaríamos quieto.

Preguntas frecuentes

¿Qué novedades de Linux 7.2 importan de verdad en un servidor?

El Cache Aware Scheduling en máquinas con muchos núcleos y varias cachés LLC, la limpieza de MGLRU y del writeback bajo presión de memoria, las mejoras de Btrfs si usas Btrfs, el bloque de 4 MB por defecto en NFS y las capacidades nuevas de KVM. El resto, incluido HDMI 2.1 FRL, apenas roza a un nodo sin entorno gráfico.

¿Linux 7.2 hace Btrfs más rápido?

En determinados escenarios sí, y con large folios activos por defecto. Los porcentajes que circulan (15 % en escrituras secuenciales, cerca de un 59 % en E/S directa) son los que reportan los parches en sus pruebas concretas y no se extrapolan a cualquier sistema. Además, si tu almacenamiento es ZFS no te afecta: OpenZFS es un módulo fuera del árbol del kernel y va por su cuenta.

¿Merece la pena actualizar ya un servidor a Linux 7.2?

Casi nunca. En producción lo razonable es seguir el kernel que mantiene tu distribución, con sus backports y sus reversiones. Linux 7.2 tampoco es una versión longterm: recibirá arreglos hasta que salga 7.3, unas nueve o diez semanas después.

Tengo Proxmox VE 9.2, ¿me pierdo algo?

Menos de lo que parece. Proxmox VE 9.2 y Proxmox Backup Server 4.2 ya van con kernel 7.0, y Proxmox integró por su cuenta los parches de MBEC y GMET, que son la novedad más citada de KVM en 7.2. Lo que llegue de 7.2 llegará empaquetado, probado y con las reversiones que hagan falta.

¿Y el planificador «justo» de GPU, está en 7.2?

El código sí, la política por defecto no. Se revirtió a FIFO antes del lanzamiento por una regresión que congelaba sesiones de escritorio con la GPU a plena carga. La idea es que vuelva como opción por defecto en Linux 7.3.

¿TCP-AO es nuevo en Linux 7.2?

No. La autenticación de segmentos TCP del RFC 5925 lleva tiempo en el kernel; lo que hace 7.2 es reimplementarla sobre la biblioteca criptográfica del propio kernel. Es un cambio interno, no una función que aparezca de golpe.

Fuentes

• Linux 7.2 llega con mejoras en CPU, Btrfs, memoria, KVM y AMDGPU — Administración de Sistemas, 18 de agosto de 2026.
• ChangeLog-7.2 — registro de cambios oficial del kernel 7.2 en kernel.org.
• Linux 7.2 — KernelNewbies, resumen de novedades con los commits de cada cambio (cifras de Btrfs, MGLRU, swap tables y NFS).
• Active kernel releases — kernel.org, ramas longterm, EOL previstos y cadencia de publicación.
• Linux 7.2 To Revert Back To The FIFO DRM Scheduler Policy Due To “Fair” Regressions — Phoronix, detalle de la regresión y de la reversión.
• Roadmap de Proxmox VE — kernel 7.0 como estable por defecto en Proxmox VE 9.2, integración de los parches MBEC y GMET, reversión de los cambios TCP de 6.17 e incidencias conocidas con 6.17.
• Roadmap de Proxmox Backup Server — Proxmox Backup Server 4.2 sobre Debian 13.4 con kernel 7.0.
• Proxmox VE Administration Guide, capítulo de administración de host — estado de la integración de BTRFS como technology preview.