En el mundo del rendimiento, no siempre ganan las grandes reescrituras. A veces, el salto llega por un detalle que parecía menor: dónde “caen” las interrupciones. Y es precisamente ahí donde ingenieros de Intel están empujando un cambio en el kernel Linux para mejorar el rendimiento de almacenamiento NVMe en servidores modernos con alto conteo de núcleos.

El problema aparece cuando el número de IRQs de NVMe es menor que el número de CPUs, algo relativamente habitual en plataformas actuales. En ese escenario, varios núcleos terminan compartiendo la misma interrupción, y si la afinidad de esa IRQ no está bien alineada con la topología real del procesador, el coste se paga en latencia y rendimiento. Intel lo resume con una idea sencilla: cuando la interrupción y el “grupo” de CPU no están cerca (en términos de cachés y localidad), se generan penalizaciones.

El cuello de botella: IRQs compartidas y topología “real” del CPU

El kernel Linux ya tiene mecanismos para repartir afinidades, pero la realidad de los procesadores actuales es que “NUMA” ya no lo explica todo. Dentro de un mismo dominio NUMA, los núcleos pueden organizarse en clústeres (por ejemplo, grupos de cores que comparten una caché intermedia) y, dependiendo de cómo se reparta la carga, un reparto “plano” puede acabar cruzando fronteras internas que no deberían cruzarse.

En el caso descrito por desarrolladores en la lista del kernel, el ejemplo práctico es el de una CPU donde 4 núcleos comparten una L2, formando un clúster; si Linux distribuye la afinidad sin tener en cuenta ese agrupamiento, la interrupción puede acabar “saltando” entre clústeres y degradando la localidad.

En otras palabras: no basta con poner la IRQ “en el mismo NUMA”; en sistemas multi-clúster dentro del propio NUMA, puede ser más eficiente que la interrupción se atienda en un core “vecino” de verdad.

Qué cambia el parche: Linux se vuelve consciente de los clústeres

La mejora propuesta hace que el código del kernel que agrupa CPUs para afinidades (en lib/group_cpus.c) sea consciente de los clústeres dentro de cada dominio NUMA. El objetivo es agrupar núcleos de manera más inteligente para que la asignación de IRQs de NVMe mantenga una mejor localidad entre CPU e interrupción.

El ingeniero de Intel Wangyang Guo lo describe así: a medida que aumenta el número de núcleos, puede haber menos IRQs de NVMe que CPUs, forzando que varios cores compartan interrupción; si la afinidad no coincide con el clúster adecuado, aparece una penalización, y el parche intenta resolverlo agrupando CPUs por clúster dentro del NUMA.

El dato que llama la atención: +15 % en lecturas aleatorias con FIO

En pruebas reportadas públicamente, el cambio mostró una mejora de alrededor del 15 % en lecturas aleatorias usando FIO con libaio, en un servidor Intel Xeon E.

Es un resultado llamativo, pero también viene con un matiz importante: por ahora, el dato está asociado a un caso concreto y no se aportan cifras para otros perfiles de I/O (secuencial, mixto, escrituras) ni para un abanico amplio de plataformas. Aun así, el enfoque encaja con una tendencia clara: el rendimiento en servidores modernos se decide tanto por el dispositivo como por el “camino” que recorre cada evento dentro del sistema.

Por qué esto importa a administradores y arquitectos de sistemas

Para perfiles de sistemas, la lectura práctica es inmediata: la afinidad de IRQ no es un detalle cosmético en entornos NVMe y alto paralelismo. Si se combinan muchos núcleos, colas NVMe y cargas de I/O intensivas (bases de datos, almacenamiento para virtualización, colas de ingestión, analítica), un reparto subóptimo puede convertirse en un freno silencioso.

Este tipo de mejora también encaja con una realidad de operaciones: en muchas infraestructuras, el NVMe ya no es “el componente rápido”, sino el componente que exige que el resto (scheduler, afinidades, colas, NUMA, caches) esté afinado para no desperdiciar rendimiento.

Qué se puede revisar hoy sin esperar a futuros kernels

Mientras este cambio madura, hay varias comprobaciones que suelen dar señales claras en sistemas con NVMe:

• Distribución de interrupciones: revisar si una o varias IRQs de NVMe concentran demasiada carga o “bailan” entre CPUs.
• Afinidad y NUMA: comprobar si las IRQs del NVMe están atendidas por CPUs del nodo NUMA más razonable para el dispositivo (especialmente en multi-socket).
• Comportamiento de irqbalance: en algunos entornos, su política por defecto no es la más adecuada para cargas deterministas; en otros, sí evita concentraciones excesivas.

No hay una receta universal, pero sí una conclusión: en plataformas de muchos núcleos, la topología importa, y cada generación tiende a añadir más capas internas (clústeres, chiplets, CCX/tiles, etc.) que no siempre quedan bien representadas con heurísticas antiguas.

Estado del cambio: en “mm-everything” y con vista a próximas ventanas de integración

Según la información publicada, el parche ha entrado en la rama “mm-everything” mantenida por Andrew Morton y podría llegar a una ventana de integración próxima del kernel (en el entorno de Linux 6.20 o incluso 7.0, según evolución y revisiones).

Como suele ocurrir con este tipo de optimizaciones, el verdadero impacto se verá cuando más gente lo pruebe en configuraciones distintas: CPUs con topologías diferentes, varios sockets, controladoras NVMe variadas y cargas reales (no solo microbenchmarks). Pero el planteamiento apunta al lugar correcto: mejorar rendimiento no siempre es “más IOPS”; a veces es menos fricción interna.

---

Preguntas frecuentes

¿A quién beneficia más este parche de NVMe en Linux?

Principalmente a sistemas con muchos núcleos donde el número de IRQs/colas NVMe no escala al mismo ritmo, provocando IRQs compartidas y potenciales penalizaciones por afinidad mal alineada con la topología del CPU.

¿Qué significa “CPU cluster-aware” en este contexto?

Que el kernel intenta agrupar CPUs por clúster dentro de cada dominio NUMA para asignar afinidades de IRQ con mejor localidad (por ejemplo, evitando saltos entre grupos de núcleos que comparten cachés internas).

¿El +15 % es un dato generalizable a cualquier servidor?

No necesariamente. El incremento reportado se obtuvo en un servidor Intel Xeon E con FIO/libaio en lecturas aleatorias, y por ahora no se publican resultados amplios para otros perfiles de I/O o hardware.

¿Cuándo podría llegar al kernel estable?

El cambio figura en la rama “mm-everything” y se menciona como candidato para una ventana de integración próxima (en el rango de Linux 6.20 ~ 7.0, sujeto a revisiones y aceptación final).