De monolitos a chiplets: por qué las CPUs modernas parecen LEGO

Por qué las CPUs se volvieron LEGO

“Monolítico” solía ser un elogio. Un die, un paquete, una jerarquía de caché, un conjunto de reglas.
Podías fingir que el silicio era un plano donde cualquier núcleo podía alcanzar cualquier byte de memoria a un coste aproximadamente igual.
Esa ficción murió por las mismas razones que mueren la mayoría de las teorías elegantes: dinero, física y planificación.

Una CPU basada en chiplets se construye a partir de varios dies más pequeños (chiplets) ensamblados en un único paquete.
Algunos chiplets contienen núcleos de CPU y cachés. Otro puede contener los controladores de memoria y E/S (PCIe, USB, SATA, CXL).
Los chiplets se comunican a través de un interconectado en el paquete.
El resultado es modular: los proveedores pueden mezclar y combinar bloques en lugar de diseñar una enorme y frágil losa de silicio.

Piensa en los chiplets menos como “múltiples CPUs en un abrigo largo” y más como una placa base de subsistemas reducida a un solo paquete.
Ganas escala y flexibilidad, pero también obtienes topología. Y la topología es donde el rendimiento puede volverse impresionante o convertirse en un incidente.

Datos interesantes y contexto histórico (lo que explica el lío actual)

• Los dies grandes tienen curvas de rendimiento brutales. A medida que aumenta el área del die, la probabilidad de que un defecto lo inutilice sube; los chiplets mantienen los dies más pequeños y aumentan el yield.
• Los módulos multi-die no son nuevos. Empaquetar varios dies en un mismo módulo existe desde hace décadas, pero el ancho de banda de interconexión moderno lo hace corriente.
• La “lógica de unión” se convirtió en característica. Las primeras aproximaciones multi-die se veían como compromisos; hoy los proveedores diseñan alrededor de ello deliberadamente.
• Los controladores de memoria se movieron on-die en los 2000. Eso ayudó a la latencia, pero también preparó el terreno para NUMA y complejidad por socket.
• El empaquetado 2.5D (interposer de silicio) cambió las reglas. Permitió enlaces de alto ancho de banda entre dies sin la penalidad tradicional a nivel de PCB.
• HBM normalizó el pensamiento en chiplets. La memoria de alto ancho de banda apilada en el paquete empujó a tratar el empaquetado como parte de la arquitectura.
• Los chiplets permiten mezclar nodos de proceso. Los núcleos de CPU pueden estar en un nodo de proceso puntero, mientras la E/S permanece en un nodo maduro, más barato y mejor para analógico.
• Existen esfuerzos de estandarización, pero la realidad es desordenada. La industria quiere chiplets interoperables; los proveedores siguen enviando ecosistemas integrados primero.

Broma #1: Si extrañas la simplicidad de las CPUs monolíticas, aún la puedes encontrar en la naturaleza—dentro de un organismo unicelular, también conocido como tu entorno de staging.

Chiplets en la práctica: CCDs, IODs, tiles e interconexiones

Los proveedores difieren en nomenclatura, pero el patrón es consistente: separar las partes de computación de las piezas de “plomería”.
La computación ama el nodo de proceso más nuevo (transistores rápidos, cachés densos). La E/S prefiere nodos estables (buenas características analógicas, tolerancia a alto voltaje, obleas más baratas).

Bloques constructivos comunes

• Chiplets de cómputo: núcleos de CPU y sus cachés cercanos (L1/L2) más un slice compartido de caché (a menudo L3).
• Die de E/S (IOD): controladores de memoria, controladores PCIe/CXL, routers de la tela, a veces aceleradores integrados.
• Interconexión: la red en el paquete que permite a los chiplets compartir memoria y coherencia de caché. Define tus costes “locales” y “remotos”.
• Sustrato de paquete / interposer: el medio físico que transporta señales. Cuanto más avanzado, más puede actuar como un pequeño backplane de alta velocidad.

Lo que ganas

Ganas flexibilidad de fabricación. Si un chiplet de cómputo es defectuoso, desechas ese pequeño die, no un monolito gigante.
También puedes construir una gama de productos poblando el paquete con distintos conteos de chiplets de cómputo—mismo die de E/S, mismo socket, distinto SKU.

Lo que pagas

Pagas en latencia y en “no uniformidad”. Dos núcleos pueden compartir la misma microarquitectura, pero no la misma distancia a la memoria.
Una línea de caché puede residir en un slice de L3 de otro chiplet. Un hilo puede rebotar entre chiplets si el scheduler o tu aplicación no tiene cuidado.

En términos de operaciones: los chiplets son una máquina de rendimiento que puede convertirse en una máquina de latencias de cola si no respetas la localidad.

La economía: rendimiento por wafer, binning y por qué los dies grandes perjudican

Los chiplets no son principalmente una historia de rendimiento. Son una historia de negocio con consecuencias de rendimiento.
La palanca más grande en el coste de semiconductores es cuántos dies buenos obtienes por wafer.
El coste del wafer sube con nodos avanzados; los defectos no disminuyen amablemente.

Rendimiento, simplificado (sin mentir demasiado)

Un wafer tiene una densidad de defectos. Un die tiene un área. Mayor área aumenta la probabilidad de que cualquier die dado intercepte un defecto.
Por eso los dies monolíticos grandes son caros incluso antes del empaquetado: se desperdicia más silicio.

Con chiplets, aceptas que algunos chiplets están malos y otros bien, y ensamblas los buenos en productos.
También puedes hacer binning de chiplets según la frecuencia o consumo alcanzable. El resultado es un uso más eficiente de lo que produce la fábrica.

Por qué mezclar nodos es ingeniería práctica, no solo contabilidad

Los nodos de vanguardia son excelentes para lógica densa y cachés, pero no son automáticamente óptimos para cada circuito.
Los PHYs y bloques analógicos a menudo se comportan mejor en nodos maduros. Además: los nodos maduros pueden tener mejor disponibilidad en la cadena de suministro.
Cuando el die de E/S se queda en un nodo maduro, reduces riesgo y puedes seguir enviando incluso cuando la capacidad de vanguardia está limitada.

La conclusión para compras: “mismo socket” ya no implica “mismo rendimiento.” Dos SKUs pueden compartir nombre y plataforma,
pero el conteo de chiplets, la disposición de caché o la revisión del die de E/S pueden cambiar el comportamiento de formas que tus benchmarks no detectarán a menos que mires.

Realidad del rendimiento: latencia, ancho de banda y topología

Los chiplets hacen que el paquete de la CPU parezca menos una losa uniforme y más un pequeño sistema NUMA.
Incluso dentro de un socket, puedes tener múltiples dominios de memoria, múltiples islas de L3 y una tela en medio.
Tu cuello de botella a menudo no es “CPU” sino “CPU más dónde viven los datos”.

Latencia: el impuesto que pagas cuando los datos están “allá”

La sensibilidad a la latencia aparece primero en p95/p99. Las cargas de trabajo de throughput pueden ocultarlo con batching y paralelismo.
Los servicios interactivos no pueden. Si la ruta de tu solicitud toca estado compartido con mala localidad, los chiplets sacarán ese coste rápidamente.

Trampas típicas de latencia:

• Acceso a memoria remota: un núcleo carga desde memoria conectada a un nodo NUMA diferente; es más lento y puede ser más variable.
• Tráfico de coherencia de caché entre chiplets: el falso compartido y escrituras frecuentes hacen que el interconectado trabaje más de lo previsto.
• Migración de hilos: el scheduler mueve tu hilo; su conjunto de trabajo caliente ya no está en las cachés “cercanas”.

Ancho de banda: los chiplets pueden ser enormes, pero no son infinitos

Un fallo común es asumir que la tela en el paquete es “prácticamente tan buena como” un die monolítico.
Es buena, pero no gratuita. Puedes saturarla con:

• Patrones de comunicación todos contra todos (barriers, colas compartidas, locks distribuidos).
• Cargas con muchas copias de memoria (serialización, staging de compresión, cifrado con mal reuso de buffers).
• Altos conteos de núcleos haciendo lo mismo a la misma región de memoria.

Topología de caché: L3 ya no es una piscina mágica única

Muchos diseños de chiplets exponen múltiples slices de L3 con acceso más rápido localmente y más lento en remoto.
Tu app no ve “L3 = 96MB” como un lago homogéneo; ve un conjunto de estanques conectados por canales.
Si tu conjunto caliente cabe en un estanque pero sigues remando entre estanques, te seguirás ahogando.

Potencia y boost: los chiplets complican “¿por qué esto está más lento hoy?”

Las CPUs modernas malabarean boost por núcleo, límites de potencia por socket, temperatura y a veces límites por chiplet.
Añadir chiplets aumenta el pico potencial de rendimiento, pero no siempre puedes boostear todo a la vez.
Conclusión para SREs: tras una renovación, “más núcleos” puede significar “menor turbo por núcleo bajo carga sostenida”, lo que cambia la latencia.

Cita (idea parafraseada): Werner Vogels: construye sistemas esperando fallos, y diseña para la resiliencia en lugar de asumir que los componentes se portarán bien.

Broma #2: Los chiplets son como microservicios—geniales hasta que te das cuenta de que has inventado una red, y ahora la depuras a las 5 a. m.

Qué cambia para SREs y equipos de plataforma

En un mundo monolítico, a menudo te salías con “Linux lo programará” y “la base de datos lo manejará”.
En un mundo de chiplets, los valores por defecto son decentes, pero no son los adecuados para tu carga.
Si te importan las latencias de cola, debes gestionar activamente la localidad: pinning de CPU, asignación de memoria consciente de NUMA, afinidad de IRQ y configuraciones BIOS sensatas.

Qué exigir a proveedores y compras

• Divulgación completa de la topología: número de nodos NUMA por socket, canales de memoria por nodo, disposición de caché y clase de ancho de banda del interconectado.
• Mapeo consistente de SKUs: si un “pequeño” stepping cambia el die de E/S o el comportamiento de memoria, quieres notas de versión y tiempo para validación.
• Comportamiento de potencia bajo carga sostenida: las políticas de turbo importan más que los relojes base de la ficha técnica.

Qué exigir a tu propia organización

• Benchmarks que coincidan con producción: los benchmarks sintéticos de CPU son entretenimiento, no evidencia.
• Planificación de capacidad consciente de topología: planifica por nodo NUMA, no solo por socket.
• Estándares de programación y pinning: los orquestadores de contenedores necesitan orientación, no optimismo.

Tareas prácticas: comandos, salidas, qué significa y qué decides

Estos son chequeos aptos para producción. Ejecútalos en un host con la “misteriosa regresión de rendimiento”.
Cada tarea incluye un comando, salida típica, qué significa la salida y la decisión que tomas.

Task 1: Ver la topología de CPU y NUMA

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               64
Thread(s) per core:                   2
Core(s) per socket:                   32
Socket(s):                            1
NUMA node(s):                         4
NUMA node0 CPU(s):                    0-15
NUMA node1 CPU(s):                    16-31
NUMA node2 CPU(s):                    32-47
NUMA node3 CPU(s):                    48-63
L3 cache:                             256 MiB

Significado: Un socket, pero cuatro nodos NUMA. Eso es localidad estilo chiplet. Tu “socket único” se comporta como un pequeño multiprocesador.

Decisión: Trata este host como NUMA. Reserva servicios sensibles a latencia en un nodo y asigna memoria localmente.

Task 2: Verificar distancias NUMA (qué tan “lejos” está realmente lo remoto)

cr0x@server:~$ numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 64000 MB
node 0 free: 52210 MB
node distances:
node   0   1   2   3
  0:  10  20  20  28
  1:  20  10  28  20
  2:  20  28  10  20
  3:  28  20  20  10

Significado: No todos los nodos remotos son iguales. “28” es notablemente peor que “20”. Algunos chiplets están más alejados.

Decisión: Para latencia estricta, mantén hilos y memoria dentro del mismo nodo; para trabajo distribuido, prefiere pares “más cercanos”.

Task 3: Confirmar que el kernel ve la política NUMA correcta

cr0x@server:~$ cat /proc/sys/kernel/numa_balancing
1

Significado: El balanceo NUMA automático está habilitado. Puede ayudar cargas generales, pero también provocar migraciones de páginas y picos de latencia.

Decisión: Para un servicio crítico de latencia, considera deshabilitarlo por host o por cgroup y gestionar afinidad explícitamente.

Task 4: Comprobar comportamiento actual de frecuencia (boost vs throttling)

cr0x@server:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgWatt,PkgTmp
Busy%  Bzy_MHz  PkgWatt  PkgTmp
72.18   3045     245.7     88

Significado: Bajo carga, los núcleos promedian ~3.0 GHz, la potencia de paquete es alta y la temperatura está cerca de los límites.

Decisión: Si p99 es peor que la generación anterior, verifica refrigeración, límites de potencia y ajustes BIOS antes de culpar al código.

Task 5: Detectar presión de ancho de banda de memoria

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,cache-misses,LLC-load-misses,LLC-store-misses sleep 10
 Performance counter stats for 'system wide':

  38,220,118,992      cycles
  52,908,331,407      instructions              #    1.38  insn per cycle
   1,182,220,114      cache-misses
     992,110,332      LLC-load-misses
      88,330,901      LLC-store-misses

      10.001024001 seconds time elapsed

Significado: Altos recuentos de miss en LLC sugieren que la carga está saliendo de caché y golpeando la memoria (o líneas de caché remotas).

Decisión: Investiga localidad: pinnea hilos, reduce el compartido entre hilos y valida la asignación de memoria por nodo NUMA.

Task 6: Identificar presión del scheduler y runqueue (¿rebotan los hilos?)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server)  01/10/2026  _x86_64_  (64 CPU)

12:04:18 AM  CPU   %usr   %sys  %iowait  %irq  %soft  %idle
12:04:19 AM  all  58.12   9.44    0.05   0.10   0.65  31.64
12:04:19 AM   0  92.00   6.00    0.00   0.00   0.00   2.00
12:04:19 AM  16  12.00  18.00    0.00   0.00   1.00  69.00
12:04:19 AM  32  86.00   9.00    0.00   0.00   0.00   5.00
12:04:19 AM  48  14.00  22.00    0.00   0.00   2.00  60.00

Significado: Algunos CPUs están calientes, otros infrautilizados, y algunos muestran tiempo de sistema elevado. Esto puede indicar desequilibrio de IRQ o mal pinning.

Decisión: Revisa la afinidad de IRQ y asegúrate de que los hilos de servicio estén pinneados consistentemente para evitar migraciones entre chiplets.

Task 7: Inspeccionar distribución de IRQ (un cuello de botella clásico oculto)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3
  24:  98211233          0          0          0   PCI-MSI 524288-edge      eth0-TxRx-0
  25:         0          0          0          0   PCI-MSI 524289-edge      eth0-TxRx-1
  26:         0          0          0          0   PCI-MSI 524290-edge      eth0-TxRx-2
  27:         0          0          0          0   PCI-MSI 524291-edge      eth0-TxRx-3

Significado: Un núcleo está manejando casi todas las interrupciones de la NIC. El chiplet local de ese núcleo podría convertirse en el “chiplet de red” por accidente.

Decisión: Habilita irqbalance o establece afinidad explícita para que las interrupciones se distribuyan entre los núcleos previstos (y preferiblemente dentro del mismo nodo NUMA que la NIC).

Task 8: Comprobar localidad del dispositivo PCIe (qué nodo NUMA posee la NIC/NVMe)

cr0x@server:~$ cat /sys/class/net/eth0/device/numa_node
2

Significado: La NIC está conectada al nodo NUMA 2. Si tu stack de red corre en el nodo 0, estás haciendo acceso remoto a memoria y bookkeeping DMA remoto.

Decisión: Pinnea hilos con mucha red al nodo 2 (o mueve las IRQ) y asigna buffers en el nodo 2 cuando sea posible.

Task 9: Confirmar que la memoria está realmente local al servicio

cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MB) for PID 12345 (myservice)
Node 0          1200.3
Node 1           980.1
Node 2          8200.7
Node 3           410.2
Total          10791.3

Significado: El proceso está mayormente en el nodo 2, pero aún tiene asignaciones considerables en otros nodos—potencial acceso cruzado entre nodos.

Decisión: Si este servicio es sensible a latencia, aprieta el binding de CPU y memoria (systemd, cgroups, taskset, numactl) para que no se disperse.

Task 10: Comprobar actividad de migración de páginas (efectos secundarios del balanceo NUMA)

cr0x@server:~$ grep -E 'pgmigrate|numa' /proc/vmstat | head -n 10
pgmigrate_success 1822331
pgmigrate_fail 1122
numa_pte_updates 998122
numa_hint_faults 288111
numa_hint_faults_local 201994
numa_pages_migrated 155002

Significado: El kernel está migrando páginas activamente. Eso puede ser bueno para throughput, pero puede añadir jitter y contención.

Decisión: Si ves picos en la latencia de cola, intenta controlar la colocación explícitamente y reduce la dependencia en la migración automática.

Task 11: Comprobar estado de huge pages (presión TLB vs fragmentación)

cr0x@server:~$ grep -E 'HugePages|Hugepagesize' /proc/meminfo
HugePages_Total:       2048
HugePages_Free:        1980
HugePages_Rsvd:          12
Hugepagesize:        2048 kB

Significado: Las huge pages están disponibles y mayormente libres; tu servicio podría no usarlas, o podría reservar algunas.

Decisión: Para servicios intensivos en memoria, valida si las huge pages reducen misses de TLB; no las habilites a ciegas si la asignación queda fragmentada entre nodos NUMA.

Task 12: Validar cgroup CPU sets para una carga containerizada

cr0x@server:~$ systemctl show myservice --property=CPUQuota --property=AllowedCPUs --property=AllowedMemoryNodes
CPUQuota=400%
AllowedCPUs=0-31
AllowedMemoryNodes=0-1

Significado: El servicio está restringido a CPUs 0–31 y nodos de memoria 0–1. Si la NIC/NVMe está en el nodo 2, acabas de construir una máquina de acceso remoto.

Decisión: Alinea CPUs y nodos de memoria con la localidad de dispositivos. Coloca el servicio donde vive su E/S o mueve dispositivos/IRQs en consecuencia.

Task 13: Prueba rápida memoria local vs remota (chequeo puntual)

cr0x@server:~$ sudo numactl --cpunodebind=0 --membind=0 bash -c 'dd if=/dev/zero of=/dev/null bs=1M count=4096'
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 0.642 s, 6.7 GB/s

cr0x@server:~$ sudo numactl --cpunodebind=0 --membind=3 bash -c 'dd if=/dev/zero of=/dev/null bs=1M count=4096'
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 0.811 s, 5.3 GB/s

Significado: El binding a memoria remota reduce el rendimiento observado. Las aplicaciones reales también pagan latencia adicional, no solo pérdida de ancho de banda.

Decisión: Si el binding remoto cambia los números materialmente, tienes una carga sensible a localidad. Trata la colocación como un requisito de primera clase.

Task 14: Inspeccionar pistas de caché y topología desde sysfs

cr0x@server:~$ for c in 0 16 32 48; do echo "cpu$c:"; cat /sys/devices/system/cpu/cpu$c/cache/index3/shared_cpu_list; done
cpu0:
0-15
cpu16:
16-31
cpu32:
32-47
cpu48:
48-63

Significado: Cada grupo de 16 CPUs comparte un L3—cuatro “islas” de L3. Esa es una frontera chiplet/cluster de caché que debes respetar.

Decisión: Pinnea hilos cooperativos dentro de una isla de L3 compartida. Mantén los pools de hilos charlatanes juntos; separa vecinos ruidosos en islas diferentes.

Guía de diagnóstico rápido: encuentra el cuello de botella antes de discutir arquitectura

Cuando un servicio empeora en CPUs de la era chiplet, el camino más rápido no es un debate profundo de microarquitectura.
Es un triage disciplinado: topología, localidad, potencia, luego código.

Primero: confirma qué es realmente la máquina

• Topología: ejecuta lscpu y numactl --hardware. Si hay > 1 nodos NUMA por socket, trátalo como sensible a topología.
• Islas de caché: revisa grupos de L3 compartidos vía sysfs (Task 14). Esto suele predecir penalizaciones cross-chiplet mejor que los nombres de marketing.
• Localidad de dispositivos: comprueba el numa_node de NIC/NVMe en sysfs. Los dispositivos anclados a un nodo pueden arrastrar tu carga completa a remoto.

Segundo: identifica si el dolor es latencia, ancho de banda o programación

• Latencia / jitter: mira p95/p99 vs media. Si la media está bien y la cola es horrible, sospecha migración, memoria remota, desequilibrio de IRQ o throttling por potencia.
• Ancho de banda: usa perf stat para misses de LLC, busca explosiones de cache-miss bajo carga. También comprueba saturación de canales de memoria si tienes herramientas del proveedor.
• Programación: usa mpstat -P ALL. Núcleos calientes y fríos sugieren problemas de pinning, puntos calientes de IRQ o distribución desigual del trabajo.

Tercero: valida políticas y colocación

• Balanceo NUMA: revisa /proc/sys/kernel/numa_balancing y estadísticas de migración en /proc/vmstat.
• cgroups / cpusets: asegúrate de que CPU y nodos de memoria se alineen con la E/S del servicio.
• Afinidad de IRQ: confirma que las interrupciones estén repartidas y locales al nodo del dispositivo.

Cuarto: solo entonces, afina o refactoriza

• Si la localidad es el problema: pinnea hilos, aplica política de memoria, reestructura asignaciones.
• Si el ancho de banda es el problema: reduce el churn de estado compartido, evita falso compartido, reduce memcpy, agrupa y considera cambios en estrategia de compresión/cifrado.
• Si la potencia es el problema: arregla refrigeración, límites de potencia y ajustes BIOS; no “optimices” el código para compensar un problema térmico.

Errores comunes (síntomas → causa raíz → solución)

1) Síntoma: la latencia p99 empeoró tras una renovación de CPU, pero la latencia media mejoró

Causa raíz: Migraciones cross-chiplet y accesos a memoria remota provocan jitter en la cola.

Solución: Pinnea hilos de manejo de peticiones dentro de una isla L3; vincula memoria al mismo nodo NUMA; reduce la migración de hilos (afinidad, menos hilos ejecutables que cores, evita pools sobredimensionados).

2) Síntoma: “la CPU solo está al 40%” pero el throughput se topea temprano

Causa raíz: Se ha saturado el ancho de banda de memoria o del fabric; más cores no ayudan una vez que estás bound por ancho de banda.

Solución: Usa perf stat para confirmar misses de caché; reduce rutas con muchas copias; perfila el comportamiento del allocator; incrementa localidad; considera sharding por NUMA.

3) Síntoma: servicio intensivo en red muestra un core al 100% en tiempo de sistema

Causa raíz: La afinidad de IRQ concentra interrupciones en una CPU; el dispositivo está en un nodo NUMA distinto al de los hilos del servicio.

Solución: Distribuye IRQs entre cores en el nodo NUMA del dispositivo; alinea el conjunto de CPUs del servicio con el mismo nodo; verifica con /proc/interrupts y sysfs.

4) Síntoma: el rendimiento varía mucho entre hosts que parecen idénticos

Causa raíz: Ajustes BIOS diferentes (límites de potencia, interleaving de memoria, SMT, ajustes NUMA); diferencias de stepping cambian el comportamiento de topología.

Solución: Estandariza perfiles BIOS; rastrea versiones de firmware; valida con una prueba de humo de topología/perf durante el aprovisionamiento.

5) Síntoma: la base de datos se vuelve más lenta al añadir hilos trabajadores

Causa raíz: Contención de locks y rebote de líneas de caché entre chiplets; falso compartido en colas/counters compartidos.

Solución: Limita hilos por isla L3; shardea datos calientes por nodo NUMA; usa contadores por core/nodo con agregación periódica.

6) Síntoma: servicio containerizado “aleatoriamente” thrashea memoria y se queda bloqueado

Causa raíz: El cpuset permite CPUs en un nodo, pero las asignaciones de memoria aterrizan en otros por defaults, migración de páginas o asignaciones compartidas del host.

Solución: Establece políticas de CPU y nodos de memoria en cgroups; verifica con numastat -p; considera deshabilitar el balanceo NUMA automático para esa carga.

Tres micro-historias corporativas de la era chiplet

Micro-historia 1: El incidente causado por una suposición equivocada

Un equipo de plataforma desplegó un nuevo servidor “single-socket, alto conteo de núcleos” para reemplazar máquinas antiguas de dos sockets. El argumento era simple:
menos sockets significan menos problemas NUMA, y el chip tenía muchos núcleos. El plan de migración trató cada host como un pool uniforme de CPU.

En una semana, una API orientada al cliente empezó a agotar tiempos en ráfagas. No era sobrecarga constante—eran ráfagas. Los gráficos eran exasperantes:
la utilización de CPU parecía saludable, la tasa de errores subió y añadir instancias ayudó menos de lo esperado.
El on-call hizo lo de siempre: revisó GC, revisó la base de datos, revisó la red.
Nada obvio.

El avance vino de revisar la topología. El “socket único” exponía cuatro nodos NUMA. La NIC estaba en el nodo 2.
El orquestador pinneó los pods a CPUs 0–31 (nodos 0 y 1) porque ese era el conjunto de CPU por defecto en la imagen del host.
Las interrupciones de red también estaban concentradas en un CPU del nodo 2. El sistema hacía un baile complicado:
los paquetes llegaban al nodo 2, eran manejados por un core IRQ en el nodo 2, se encolaban en memoria no siempre local,
luego hilos trabajadores en nodos 0/1 tiraban del trabajo remotamente. El tráfico cross-node más jitter de scheduling dejó la p99 pésima.

Arreglarlo fue aburrido: alinear cpusets y nodos de memoria con la localidad de la NIC, dispersar IRQs por ese nodo y mantener los hilos de petición cerca de sus buffers.
El servicio se estabilizó. La lección principal del postmortem también fue aburrida: “socket único” no es sinónimo de “memoria uniforme.” En sistemas chiplet, nunca lo fue.

La acción de seguimiento que importó: el equipo añadió una puerta de aprovisionamiento que rechazaba hosts donde el nodo NUMA del dispositivo no coincidía con el conjunto de CPU previsto.
No fue glamoroso, pero evitó repetirlo.

Micro-historia 2: La optimización que salió mal

Un equipo de pipeline de datos optimizó un camino caliente aumentando el paralelismo. Cogieron un job batch que corría con 32 hilos trabajadores y lo “escalaron”
a 128 hilos en la nueva generación de CPUs chiplet de alto conteo de núcleos. Su razonamiento era de libro: más cores, más hilos, más throughput.

El primer benchmark se vio bien—brevemente. En ejecuciones cortas, el throughput mejoró. En ejecuciones largas, el throughput degradó y se volvió ruidoso.
El rendimiento agregado del clúster se volvió inconsistente, y el tiempo de reloj del job dejó de mejorar.
Mientras tanto, otros servicios en los mismos hosts empezaron a quejarse de latencia aunque “esto es solo un job batch.”

El análisis de la raíz mostró presión en el interconectado y memoria, no saturación de CPU. La carga tenía una cola de trabajo compartida
y unos pocos contadores globales actualizados con frecuencia. En un die monolítico eso era molesto pero tolerable.
En una topología chiplet con múltiples islas L3, se convirtió en un generador de tráfico de coherencia.
Suma migraciones de hilos y obtienes exactamente lo que los contadores perf predijeron: muchos cache misses y mucho parloteo cross-node.

La “solución” fue reducir paralelismo, no aumentarlo. Limitaron hilos por isla L3 e introdujeron colas y contadores por nodo.
El job usó menos hilos pero terminó antes y dejó de maltratar al resto del nodo.
La lección dolorosa: las CPUs de la era chiplet castigan el diseño descuidado de estado compartido. Lanzar hilos no es escalar; es una estrategia de negación.

Después, el equipo cambió su rúbrica de rendimiento: cualquier optimización que aumente el compartido entre hilos debe incluir un benchmark consciente de topología,
de lo contrario no se envía. Además dejaron de celebrar “la utilización de CPU subió” como victoria. Utilización no es throughput, y definitivamente no es latencia de cola.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un grupo de infraestructura gestionaba una flota mixta: dos generaciones de CPU, múltiples versiones de BIOS y un ritmo de actualizaciones de firmware.
No eran héroes. Eran solo organizados.
Cada host aprovisionado pasaba por una canalización de “burn-in” que recopilaba topología, localidad de dispositivos y un pequeño set de contadores de rendimiento bajo carga.

Una semana, notaron un cambio sutil: un subconjunto de hosts nuevos mostraba ratios más altos de acceso remoto a memoria en la misma prueba sintética de colocación.
Las máquinas no estaban fallando, y nadie había abierto un ticket. La canalización lo detectó porque la línea base incluía distancia NUMA y un microbenchmark
fijado local vs remoto.

El culpable fue una deriva del perfil BIOS. Un técnico bienintencionado usó un preset “performance” del proveedor que cambió el comportamiento de interleaving de memoria.
No rompió la máquina; solo desplazó la localidad lo suficiente para importar a servicios sensibles a latencia.
Sin la canalización de burn-in, esto habría llegado como “regresiones aleatorias” semanas después.

Revertieron el perfil, re-imaginaron un puñado de hosts y siguieron. Sin outage, sin reuniones de emergencia.
La práctica que los salvó no fue genial. Fue consistencia: trata la topología y la localidad como parte de la deriva de configuración, y pruébalo como pruebas de salud de disco.

Listas de verificación / plan paso a paso

Checklist: adoptar CPUs de la era chiplet sin crear un horror de latencia

1. Inventario de topología: registra nodos NUMA por socket, grupos L3 compartidos, canales de memoria y nodos NUMA de dispositivos.
2. Define clases de carga: crítico de latencia, throughput, batch, background ruidoso. No todo obtiene las mismas reglas de colocación.
3. Elige política de colocación:
   • Crítico de latencia: pinnea dentro de una isla L3 y un nodo NUMA.
   • Throughput: shardea por nodo NUMA; escala fuera entre nodos si los datos son particionables.
   • Batch: aisla a nodos/cores específicos; limita los hogs de ancho de banda.
4. Alinea la localidad de E/S: coloca servicios intensivos en red o NVMe en el nodo NUMA adjunto a esos dispositivos.
5. Estandariza BIOS y firmware: un perfil, versión registrada, cambios desplegados mediante canarios.
6. Valida comportamiento de potencia: verifica relojes sostenidos bajo tu carga real, no solo “que hace boost una vez.”
7. Construye una prueba de humo: ejecuta una prueba local-vs-remota de memoria y una captura breve de contadores perf durante el aprovisionamiento.
8. Enseña a tu scheduler: codifica políticas cpuset/mems en unidades systemd o labels de nodo y specs de pod en el orquestador.
9. Documenta modos de fallo: desequilibrio de IRQ, memoria remota, contención de locks cross-node, throttling térmico.
10. Despliega con canarios: compara p99, no solo throughput. Requiere criterios de rollback.

Paso a paso: arreglar una regresión de localidad en un host en vivo

1. Ejecuta lscpu y numactl --hardware; anota nodos, rangos de CPU, distancias.
2. Encuentra la localidad del dispositivo NIC/NVMe vía sysfs numa_node.
3. Revisa la distribución de IRQ (/proc/interrupts) y corrige afinidad si un core está sobrecargado.
4. Revisa el cpuset y la política de nodos de memoria del servicio (propiedades systemd o archivos cgroup).
5. Usa numastat -p para confirmar que la memoria del servicio coincide con su colocación de CPU.
6. Deshabilita el balanceo NUMA automático para ese servicio si provoca churn de migraciones; vuelve a probar p99.
7. Limita pools de hilos para que quepan dentro de una isla L3 cuando sea posible; evita contención cross-isla.
8. Vuelve a ejecutar una breve prueba de carga y compara p50/p95/p99 además de contadores perf.

Preguntas frecuentes

1) ¿Los chiplets siempre son más lentos que las CPUs monolíticas?

No. Los chiplets suelen ofrecer mejor throughput, más núcleos, caché agregada mayor y mejor economía. Son “más lentos” solo cuando tu carga
paga impuestos por acceso remoto y tráfico de coherencia que no planeaste—típicamente visible en la latencia de cola.

2) ¿Por qué no simplemente hacer el interconectado tan rápido que no importe?

Por física y potencia. Impulsar señales de alta velocidad cuesta energía y genera calor. Además: la latencia es persistente; puedes comprar ancho de banda más fácil que tiempo de ida y vuelta.

3) ¿NUMA es lo mismo que chiplets?

No es lo mismo, pero riman. NUMA es el modelo de rendimiento: el tiempo de acceso a memoria depende de qué controlador de memoria posee la página.
Los chiplets son un enfoque de empaquetado/arquitectura que frecuentemente crea múltiples dominios de memoria e islas de caché incluso dentro de un socket.

4) Si Linux ve un socket, ¿por qué debería importarme?

Porque “socket” es una etiqueta contable. Linux aún puede exponer varios nodos NUMA y grupos de caché separados.
A tu carga le importa dónde están las páginas de memoria y qué cores comparten caché, no cuántos sockets físicos hay.

5) ¿Necesito pinnear todo a CPUs ahora?

No todo. El pinning es una herramienta, no una religión. Úsala para servicios críticos de latencia, redes de alto rendimiento y cualquier cosa con localidad estricta de caché.
Para cargas stateless de propósito general, el scheduling por defecto puede estar bien—hasta que veas deriva en p99.

6) ¿Cuál es el error más grande que cometen los equipos durante renovaciones?

Asumir que la nueva CPU es simplemente “la vieja CPU pero más rápida.” Los chiplets cambian topología, comportamiento de caché y dinámica de potencia.
Si no mides localidad y relojes sostenidos bajo tu carga, haces una renovación por intuición.

7) ¿Más caché L3 significa menos problemas?

Más caché ayuda, pero la topología importa. Si la caché está particionada en islas y tus hilos rebotan entre islas, aún puedes fallar “más a menudo de lo que esperas.”
Usa los grupos L3 compartidos como frontera de colocación.

8) ¿Cómo afectan los chiplets a la virtualización y contenedores?

Aumentan el coste de la colocación descuidada. VMs y contenedores pueden acabar con vCPUs repartidas por nodos NUMA mientras su memoria está en otro sitio.
Arréglalo con políticas de CPU y memoria (cpuset + mems), y valida con numastat y chequeos de topología.

9) ¿Los chiplets aumentan las tasas de fallo?

No inherentemente. Cambian dónde reside el riesgo: empaquetado e interconexiones más complejas, pero a menudo mejores yields y binning.
Operativamente, tu principal “falla” es la imprevisibilidad de rendimiento, no fallos de hardware evidentes.

10) ¿Qué debo benchmarkear para comparar dos CPUs con chiplets?

Mide tu carga con concurrencia realista, tamaños de datos realistas y E/S realista. Registra p99, no solo promedio.
También registra la topología (distancias NUMA, compartición L3) para poder explicar diferencias en lugar de discutirlas.

Siguientes pasos que puedes hacer esta semana

Los chiplets no son una moda. Son la vía por defecto para escalar conteo de núcleos y mezclar nodos de proceso. Luchar contra eso es como luchar contra la gravedad:
puedes hacerlo brevemente, pero no quedarás bien en la llamada de incidentes.

1. Añade topología a los facts de tus hosts: almacena lscpu, numactl --hardware, grupos L3 compartidos y nodos NUMA de dispositivos en tu inventario.
2. Haz la colocación explícita: para un servicio crítico de latencia, implementa binding de CPU y memoria y documenta la razón.
3. Audita afinidad de IRQ en tus hosts más cargados. Si un core lleva todo, arréglalo y consigue una victoria rápida.
4. Crea una prueba de humo “local vs remote” durante el aprovisionamiento para que la deriva de BIOS y steppings raros se detecten antes del tráfico de producción.
5. Reescribe un hotspot de estado compartido: sustituye un contador/cola global por sharding por NUMA o por core, y luego mide la latencia de cola.

El objetivo no es convertirte en un arquitecto de CPUs. Es dejar de sorprenderte por la física que puedes medir en 30 segundos.
Las CPUs chiplet parecen LEGO porque la manufactura y la economía lo exigieron. Tu trabajo es operarlas como si fueran modulares, porque lo son.