Localidad de caché y NUMA: medir y diseñar para escalar

Las cuatro lecciones anteriores fueron herramientas; esta es el juicio para usarlas. En una máquina grande, dos programas idénticos pueden diferir 5x en rendimiento solo por dónde vive su memoria y cómo comparten sus líneas de caché. Y lo que no se mide no se arregla. Aquí aprendes a ver el desequilibrio NUMA y el false sharing con las herramientas del kernel, y a diseñar datos que respeten la topología. Es el cierre del nivel: la localidad no es un detalle de afinado, es la variable maestra del rendimiento a escala.

Medir el desequilibrio NUMA

La primera pregunta es si tu carga asigna local o remoto. numastat lee los contadores por nodo que el kernel mantiene en mm/vmstat.c:

# Contadores globales por nodo: aciertos locales vs accesos remotos
numastat

# Por proceso: cuanta memoria de cada nodo usa
numastat -p $(pgrep mi_servidor)

# El desglose crudo de un nodo
cat /sys/devices/system/node/node0/numastat

Los contadores que importan: numa_hit (asignaciones que consiguieron el nodo deseado), numa_miss (querían un nodo pero cayeron en otro), numa_foreign (destinadas aquí pero servidas en otro sitio), local_node y other_node (asignadas en el nodo del núcleo que las pidió, o no). Un numa_miss alto o mucho other_node es el síntoma inequívoco de páginas mal colocadas. Para ver qué rango vive dónde, numa_maps desglosa cada VMA del proceso por nodo:

cat /proc/$(pgrep mi_servidor)/numa_maps
# ...heap anon=262144 dirty=262144 N0=131072 N1=131072  <- repartido 50/50
# ...       anon=524288 dirty=524288 N0=524288           <- TODO en el nodo 0

Esa segunda línea —todo el buffer en un solo nodo— es el fallo de first-touch (26.2) hecho visible.

Cazar el false sharing

El false sharing es el asesino silencioso de la escalabilidad, y es un problema de la escala más fina: la línea de caché (64 bytes en x86-64). Dos variables lógicamente independientes que caen en la misma línea comparten destino físico: si el núcleo A escribe una y el núcleo B escribe la otra, el protocolo de coherencia hace rebotar la línea entre sus cachés en cada escritura, aunque nunca toquen el mismo byte. La herramienta que lo caza es perf c2c (cache-to-cache):

# Graba las transferencias de cache con modificacion (HITM)
perf c2c record -a -- sleep 10
perf c2c report --stdio

# Y directo de la PMU: fallos que se resuelven en otra cache
perf stat -e node-loads,node-load-misses,LLC-load-misses ./bench

El informe de perf c2c señala las líneas de caché con más HITM (Hit Modified: una carga que encontró el dato modificado en la caché de otro núcleo, la firma exacta del rebote) y, mejor aún, el offset dentro de la línea de cada acceso en conflicto, apuntando con el dedo a los campos culpables de tu estructura.

Diseñar para la localidad

La cura del false sharing es empujar los campos calientes a líneas de caché distintas con ____cacheline_aligned_in_smp (include/linux/cache.h):

#include <linux/cache.h>

/* MAL: dos contadores martilleados por nucleos distintos, misma linea */
struct stats_malo {
	atomic_t rx;   /* lo golpea el nucleo A */
	atomic_t tx;   /* lo golpea el nucleo B -> la linea rebota */
};

/* BIEN: cada campo caliente en su propia linea de cache */
struct stats_bueno {
	atomic_t rx ____cacheline_aligned_in_smp;
	atomic_t tx ____cacheline_aligned_in_smp;
};

El sufijo _in_smp es fino: en un kernel uniprocesador el relleno desaparece y no malgastas memoria. El tamaño de línea es SMP_CACHE_BYTES (derivado de L1_CACHE_BYTES, 64 en x86-64), y cache_line_size() lo da en runtime. La cara opuesta de la misma moneda es agrupar a propósito los campos que siempre se usan juntos en la misma línea para maximizar la localidad espacial: separar lo que compite, juntar lo que coopera.

Y a la escala mayor, el diseño consciente del nodo: réplicas de la estructura por nodo, cada núcleo tocando la suya (variables per-CPU, 26.3), memoria asignada con kmalloc_node/alloc_pages_node en el nodo del hilo o del dispositivo (26.2), y en el espacio de usuario, hilos anclados con sched_setaffinity o numactl --cpunodebind para que cómputo y datos no se separen jamás.

flowchart TD
A[Dos variables calientes en la misma linea de cache] --> B[El nucleo 0 escribe la variable X]
A --> C[El nucleo 1 escribe la variable Y]
B --> D[La linea rebota entre las caches sin necesidad real]
C --> D
D --> E[perf c2c ve el HITM y senala el campo culpable]
E --> F[Separar con cacheline aligned elimina el rebote]
style D fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b