Linux 7.2 rendimiento AMD EPYC: mejora sorpresa

El kernel Linux 7.2 apareció con una sorpresa que nadie tenía en el roadmap: mejoras de rendimiento en la red local (localhost) sobre servidores AMD EPYC. Lo detectó Phoronix el 23 de junio de 2026 durante benchmarks tempranos en un EPYC 8005 “Sorano” de 84 núcleos, comparando Linux 7.1 estable contra Linux 7.2 Git. El rendimiento de TCP mejoró de forma clara, sin que fuera un objetivo declarado.

Linux 7.2 es la próxima versión del kernel de Linux, todavía en ventana de merge (cierra ese fin de semana del 21 de junio de 2026). Trae cache aware scheduling como cambio destacado y, según los primeros tests de Phoronix, ganancias inesperadas en el rendimiento de sockets y red localhost. Lo midieron sobre un AMD EPYC 8005 “Sorano” con arquitectura Zen 5, usando xfr, una herramienta de benchmark escrita en Rust.

En 30 segundos

Mejora inesperada: Linux 7.2 mostró ganancias de rendimiento en red localhost (sockets/TCP) que no estaban en el roadmap, detectadas el 23 de junio de 2026.
Hardware de prueba: un AMD EPYC 8005 “Sorano”, el tope de gama con 84 núcleos y 168 hilos sobre Zen 5.
Cómo se midió: Linux 7.1 estable contra Linux 7.2 Git del 21 de junio, usando xfr, la alternativa moderna en Rust a iperf3.
La estrella anunciada: cache aware scheduling, una optimización del planificador pensada para procesadores con muchos núcleos.
Disponibilidad: 7.2 sale a producción después de cerrar la ventana de merge; Phoronix promete benchmarks completos en más hardware.

¿Qué mejoras inesperadas encontró Linux 7.2 en performance de red?

Ponele que estás haciendo benchmarks de un kernel nuevo esperando ver el impacto de la feature grande del ciclo, y de repente el que salta es un número que nadie te prometió. Eso le pasó a Michael Larabel de Phoronix con Linux 7.2.

La feature que tenía a todos mirando era cache aware scheduling. Pero en las pruebas tempranas de esta semana, lo que apareció fue otra cosa: mejoras en el rendimiento de red y sockets a nivel localhost. No era un cambio anunciado en las notas del ciclo, no estaba en el “qué esperar de 7.2”, y aun así estaba ahí en los números.

¿Por qué importa el localhost si “es solo la máquina hablando consigo misma”? Porque ahí viven un montón de cargas reales. Proxies inversos, contenedores que se comunican entre sí, bases de datos y aplicaciones en el mismo host, sidecars de service mesh. Toda esa conversación pasa por el loopback, y si el kernel la hace más rápida, ganás sin tocar una línea de tu código. Tema relacionado: infraestructura moderna de integración continua.

¿Cómo funciona cache aware scheduling en Linux 7.2?

El cache aware scheduling es una optimización del planificador del kernel que tiene en cuenta la topología de caché de la CPU al decidir en qué núcleo corre cada tarea. La idea: mantener los hilos relacionados cerca de los datos que ya están “calientes” en la caché compartida, en vez de mandarlos a un núcleo lejano donde tienen que volver a traer todo desde memoria.

El tema es que en un procesador con pocos núcleos esto casi no se nota. Pero en una bestia de 84 núcleos, donde la caché está repartida en varios complejos (CCX/CCD en la jerga de AMD), mover una tarea al lugar equivocado te cuesta caro. Cada salto a memoria principal es un ciclo perdido.

Acá viene lo bueno: cuando el planificador respeta la localidad de caché, las tareas que comparten datos terminan compartiendo también la misma porción de caché. Menos cache misses, menos latencia, más throughput. Y eso se combina, probablemente, con las mejoras de red que vio Phoronix, porque la pila de TCP en localhost es muy sensible a dónde se programan los procesos que mandan y reciben.

AMD EPYC 8005 “Sorano”: ¿por qué este servidor muestra estas ganancias?

El sistema de prueba fue un servidor con el nuevo AMD EPYC 8005 “Sorano”, el modelo tope de la serie: 84 núcleos y 168 hilos sobre arquitectura Zen 5. No es un chip cualquiera de escritorio. Es justo el tipo de hardware donde los cambios del planificador se amplifican.

La lógica es simple. Con 84 núcleos, el kernel tiene 84 lugares posibles donde poner cada tarea, y la diferencia entre el lugar bueno y el malo se multiplica. Un parche que en una CPU de 8 núcleos te da una mejora marginal, en este monstruo puede dar un salto medible. Por eso el primer sistema que Larabel eligió para evaluar 7.2 fue justamente un EPYC de alto recuento de núcleos. Esto se conecta con lo que analizamos en pipelines de automatización en servidores escalables.

Eso sí: que la mejora se vea grande acá no significa que sea exclusiva de AMD. Lo desarrollamos más abajo.

¿Cuánto mejora el rendimiento de TCP en los benchmarks de Linux 7.2?

Acá toca ser honesto. Phoronix comparó Linux 7.1 estable contra Linux 7.2 Git del 21 de junio de 2026 y describió la mejora de TCP en localhost como “muy linda” (improved very nicely). La nota preliminar no publicó todavía la cifra exacta del salto porcentual, y no la vamos a inventar. Cuando salga el análisis completo, el número va a estar en la cobertura de Phoronix.

Lo que sí sabemos es con qué se midió: xfr, una herramienta de benchmark de red escrita en Rust que se posiciona como alternativa moderna a iperf3. xfr es un medidor de throughput de red que genera tráfico controlado entre dos puntos (en este caso, el mismo host) y reporta cuántos datos pasan por segundo. Sirve para aislar el rendimiento de la pila de red del kernel sin que se metan variables de la red física.

Dato	Detalle confirmado
Kernel comparado	Linux 7.1 estable vs Linux 7.2 Git (21 jun 2026)
Hardware	AMD EPYC 8005 “Sorano”, 84 núcleos / 168 hilos, Zen 5
Herramienta	xfr (benchmark de red en Rust, alternativa a iperf3)
Escenario	Rendimiento localhost (loopback), TCP
Resultado	Mejora “muy buena” en TCP (cifra exacta pendiente)
Feature destacada del ciclo	cache aware scheduling

linux 7.2 rendimiento amd epyc diagrama explicativo

¿Qué otros cambios trae Linux 7.2 además de las mejoras de red?

El cambio que más ruido hizo antes de estos benchmarks fue el cache aware scheduling, que ya tratamos arriba. Pero conviene entender el contexto del ciclo para no sacar conclusiones apuradas.

Un kernel de Linux se arma en fases. Primero está la ventana de merge, que es el período donde se aceptan funcionalidades nuevas. En el caso de 7.2, esa ventana cerraba el fin de semana del 21 de junio de 2026. Después arrancan los release candidates (rc1, rc2, y así), donde ya no entran features y solo se corrigen bugs, hasta llegar a la versión estable.

Por eso Larabel aclaró que sus pruebas son tempranas: el código todavía se está moviendo. Lo que probó es lo que estaba staged al 21 de junio, y la lista definitiva de novedades de 7.2 se cierra recién cuando termina la ventana. La promesa de Phoronix es un panorama completo del rendimiento del kernel apenas eso suceda, con más benchmarks y más hardware. Ya lo cubrimos antes en agentes que corren en hardware propio.

¿Cuándo sale Linux 7.2 y cómo afecta a hosting y servidores web?

El timeline típico de un kernel desde que cierra la ventana de merge hasta la estable es de unas siete u ocho semanas de release candidates. Con la ventana de 7.2 cerrando a fines de junio de 2026, la versión final aterrizaría en agosto, salvo que aparezca alguna regresión que lo demore. Después llega la parte lenta de verdad: que las distribuciones de servidor lo adopten en sus ramas soportadas.

¿Por qué te tendría que importar si gestionás hosting o infraestructura web? Porque las mejoras de localhost y de scheduling pegan justo donde duele en producción. Una VPS o un servidor dedicado donde corren Nginx, PHP-FPM, una base de datos y Redis, todos charlando por loopback, es exactamente el escenario que se beneficia. Más throughput de red local y mejor uso de caché se traducen en más requests por segundo con el mismo fierro.

Si estás montando infraestructura sobre servidores AMD EPYC o cloud en Argentina, podés arrancar con la VPS y los planes de donweb.com y, cuando tu distribución incorpore un kernel 7.2 o posterior, te llevás estas optimizaciones casi de arriba (suponiendo que el resto de tu stack esté afinado, claro).

¿Qué sistemas se benefician más allá de AMD EPYC?

Esta es la parte que conviene no malinterpretar. El benchmark se hizo en AMD, pero ni el cache aware scheduling ni las mejoras de la pila de red son código específico de AMD. Son cambios en el kernel genérico de Linux.

Procesadores Intel y ARM de muchos núcleos: el cache aware scheduling aplica a cualquier arquitectura con caché jerárquica. Un Xeon de alto recuento o un ARM server-grade también deberían ver beneficio.
Cargas con mucho tráfico localhost: contenedores, microservicios en el mismo host, proxies y bases de datos locales. La arquitectura de CPU importa menos que el patrón de comunicación.
Servidores de pocos núcleos: probablemente vean menos diferencia, porque hay menos margen para que el planificador “elija mal” dónde poner una tarea.

Tomalo con pinzas igual: hasta que Phoronix no publique los benchmarks en otro hardware, el dato duro lo tenemos solo sobre el EPYC Sorano. Habría que ver cuánto se replica en Intel o ARM.

Qué está confirmado y qué no

Confirmado: Linux 7.2 mostró mejoras de rendimiento en red localhost/TCP sobre un AMD EPYC 8005 “Sorano”, medidas con xfr, comparando 7.1 estable contra 7.2 Git del 21 de junio de 2026.
Confirmado: el ciclo incluye cache aware scheduling y la ventana de merge cerraba el fin de semana del 21 de junio.
Pendiente: la cifra exacta de mejora de TCP. Phoronix la describió como “muy buena” pero no publicó el porcentaje en la nota preliminar.
Pendiente: benchmarks en hardware no-AMD (Intel, ARM) y el análisis de rendimiento completo del kernel.
Pendiente: la fecha estable definitiva de 7.2, sujeta al ciclo de release candidates.

Errores comunes al leer estos benchmarks

Creer que ya podés instalarlo en producción: 7.2 está en código Git, no en versión estable. Meter un kernel en ventana de merge en un servidor productivo es pedir un dolor de cabeza. Esperá la estable y, mejor todavía, a que tu distribución la empaquete.
Pensar que la mejora es solo de AMD: el código es genérico del kernel. El benchmark se hizo en EPYC porque ahí se nota más, no porque sea exclusivo. Asumir que Intel queda afuera es un error.
Confundir localhost con red real: la mejora medida es en loopback. No quiere decir automáticamente que tu tráfico entre dos servidores físicos vaya a saltar igual. Son pilas distintas; el dato de localhost no se extrapola a la red externa sin medirlo.
Tomar “mejora muy buena” como un número: sin la cifra publicada, cualquier porcentaje que veas circular por ahí es invento. Esperá el dato oficial.

Preguntas Frecuentes

¿Qué es cache aware scheduling en Linux?

Cache aware scheduling es una optimización del planificador del kernel que ubica las tareas según la topología de caché de la CPU, manteniendo juntos los hilos que comparten datos. Reduce los cache misses y la latencia, sobre todo en procesadores con muchos núcleos y caché repartida en varios complejos. Te puede servir nuestra cobertura de cargas de trabajo de IA de alto rendimiento.

¿Cuándo sale Linux 7.2 estable?

La ventana de merge de Linux 7.2 cerraba el fin de semana del 21 de junio de 2026. Tras unas siete u ocho semanas de release candidates, la versión estable llegaría alrededor de agosto de 2026, salvo regresiones que la demoren. La adopción en distribuciones de servidor toma más tiempo.

¿Qué es el AMD EPYC 8005 “Sorano”?

El AMD EPYC 8005 “Sorano” es una serie de procesadores de servidor de AMD. El modelo tope usado en los tests de Phoronix tiene 84 núcleos y 168 hilos sobre arquitectura Zen 5, orientado a cargas de alto recuento de núcleos como virtualización, contenedores y cómputo intensivo.

¿Qué es xfr y por qué se usó en lugar de iperf3?

xfr es una herramienta de benchmark de red escrita en Rust, presentada como alternativa moderna a iperf3. Mide throughput generando tráfico controlado entre dos puntos. Phoronix la usó para evaluar el rendimiento de la pila de red del kernel en localhost de forma aislada.

¿Las mejoras de Linux 7.2 sirven en procesadores Intel?

Probablemente sí, porque tanto el cache aware scheduling como las mejoras de red son código genérico del kernel, no específico de AMD. Phoronix midió primero en EPYC porque ahí el impacto se amplifica, pero todavía no publicó benchmarks en Intel o ARM para confirmar la magnitud.

Conclusión

Lo que cambió con Linux 7.2 es que, además de la feature esperada (cache aware scheduling), aparecieron mejoras de red localhost que nadie había anunciado. Eso es interesante porque las ganancias “gratis” del kernel, las que te llevás sin tocar tu aplicación, son las que más rinden a largo plazo en infraestructura.

Por qué importa: si corrés stacks web con mucho tráfico entre procesos del mismo host, este tipo de mejora se nota en requests por segundo reales. Qué hacer ahora: nada apurado. No instales un kernel Git en producción. Anotá 7.2 en el radar, esperá la versión estable y los benchmarks completos de Phoronix con la cifra de TCP confirmada y datos en otro hardware. Cuando tu distribución de servidor lo incorpore, vas a tener el cálculo claro de cuánto ganás. Por ahora, una sorpresa linda y bien encaminada.

Linux 7.2 sorprende con mas rendimiento en AMD EPYC