AMD Bulldozer: el diseño audaz que no cumplió

Qué intentó Bulldozer (y por qué sonaba razonable)

Bulldozer llegó con una apuesta: el mundo se estaba volviendo ancho. Hilos por todas partes. Servidores web, máquinas virtuales, trabajos en segundo plano, pipelines por lotes: más trabajo ejecutable del que podías lanzar a un “núcleo gordo” convencional sin desperdiciar silicio.

La respuesta de AMD fue el módulo. Cada módulo contenía dos núcleos enteros que compartían algunas piezas front-end costosas y recursos de punto flotante. El argumento: para cargas muy paralelas, obtienes un rendimiento cercano a 2x por menos de 2x área y consumo. Es como construir dos apartamentos tipo estudio que comparten cocina. Eficiente—hasta que ambos inquilinos deciden cocinar la cena de Acción de Gracias al mismo tiempo.

El diseño no fue una novedad pura. Se alineaba con una tendencia: los centros de datos se preocupaban por el rendimiento por rack, no solo por las heroicidades de un solo hilo. Y AMD tenía un problema real que resolver: no podían seguir escalando los núcleos monolíticos tradicionales al mismo ritmo que las microarquitecturas dominantes de Intel por entonces.

Donde la apuesta se torció: el software no programaba ni compilaba de forma “consciente del módulo” de manera natural. Muchas cargas reales no eran tan paralelas como la hoja de ruta asumía. Y las piezas compartidas—especialmente el front-end y el punto flotante—se convirtieron en cuellos de botella en precisamente los lugares donde no los querías: sistemas sensibles a la latencia, cargas mixtas y cualquier cosa que parezca “unos pocos hilos calientes haciendo trabajo real.”

Aquí está el encuadre operativo confiable: Bulldozer no era una “CPU mala.” Era una CPU que exigía que entendieras dónde está realmente tu cuello de botella. Si fallabas en adivinar, no perdías 5%. Perdías el trimestre.

Hechos y contexto que realmente deberías recordar

La trivia histórica solo es útil si cambia tus decisiones. Estos puntos sí lo hacen.

1. Bulldozer debutó en 2011 (series FX para escritorios, Opteron 6200 para servidores), reemplazando núcleos estilo K10/Phenom II con el enfoque por módulos.
2. Las piezas “de ocho núcleos” FX eran típicamente cuatro módulos: ocho núcleos enteros, pero no ocho front-end y unidades FP totalmente independientes.
3. Cada módulo compartía un único complejo de punto flotante (dos FMAC de 128 bits que podían combinarse para 256 bits AVX), por lo que el dual-threading intensivo en FP por módulo podía competir por recursos.
4. Hubo una historia real con el scheduler de Linux: al principio, los planificadores podían empacar hilos de forma ineficiente, causando contención intra-módulo evitable.
5. El scheduler de Windows también importaba: la colocación de hilos afectaba el rendimiento de formas que los usuarios no estaban acostumbrados a ver en núcleos convencionales.
6. Bulldozer introdujo soporte AVX para AMD, pero la implementación y el comportamiento del pipeline circundante no siempre se tradujeron en ganancias en el mundo real.
7. El comportamiento de potencia y turbo era central: las frecuencias publicitadas se veían bien en las cajas, pero los relojes sostenidos bajo carga podían ser una realidad más cálida y distinta.
8. No fue un solo intento: Piledriver y las iteraciones posteriores mejoraron piezas (frecuencia, algo de IPC, manejo de potencia), pero la apuesta fundamental por el módulo permaneció.

Un chiste seco, como limpiador de paladar: el marketing de Bulldozer enseñó una lección importante—“hasta” es la unidad de medida de la esperanza, no del rendimiento.

La realidad del módulo: adónde fueron los ciclos

1) Front-end compartido: fetch/decode no es gratis

Los núcleos modernos viven o mueren según qué tan bien mantienen alimentado el back-end de ejecución. El módulo de Bulldozer compartía la maquinaria principal del front-end entre los dos núcleos enteros. Eso significa que cuando ejecutas dos hilos ocupados en un módulo, pueden chocar en la etapa de “preparar instrucciones” antes incluso de discutir sobre los puertos de ejecución.

En términos prácticos: dos hilos enteros que parecen “ligeros” en porcentaje de CPU aún pueden ser pesados en presión del front-end: muchas bifurcaciones, gran huella de código, mucho churn en la caché de instrucciones, mucha demanda de decodificación. Tu monitor dice “la CPU está bien”, pero tu latencia dice otra cosa.

2) FP compartido: el impuesto silencioso en cargas mixtas

Los recursos de punto flotante de Bulldozer se compartían dentro del módulo. Si tenías un hilo intensivo en FP y otro principalmente entero, podrías estar bien. Si tenías dos hilos intensivos en FP fijados (o programados) en el mismo módulo, podrías obtener un rendimiento que se siente como si alguien reemplazó tu CPU por un comité educado.

Esto es especialmente relevante para:

• pipelines de compresión/descompresión
• pilas criptográficas que usan matemáticas vectorizadas
• procesamiento de medios
• código científico
• algunos comportamientos de JVM y .NET bajo rutas vectoriales JIT optimizadas

3) IPC: la brecha incómoda

El gran titular público para Bulldozer fue la decepción de IPC (instrucciones por ciclo) comparado con los contemporáneos de Intel. Puedes hablar todo el día sobre la profundidad del pipeline, el comportamiento de las ramas y los efectos de caché. Los operadores lo experimentan como:
“¿Por qué esta máquina de 3,6 GHz se siente más lenta que esa de 3,2 GHz?”

IPC es un síntoma compuesto. Es lo que ves cuando el front-end no puede alimentar el back-end, cuando la especulación no compensa, cuando la latencia de memoria no se oculta bien y cuando tu carga no se alinea con las suposiciones de la CPU. Las suposiciones de Bulldozer se inclinaban fuertemente hacia muchos hilos ejecutables y menos casos de “un hilo caliente que debe ser rápido”.

4) El módulo es una unidad de planificación te guste o no

Si tratas una CPU Bulldozer de 8 núcleos enteros como “8 núcleos simétricos”, tomarás malas decisiones. El límite del módulo importa para la contención. Esto no es filosófico. Es medible.

Cuando los planificadores son conscientes del módulo, intentan dispersar primero los hilos calientes entre módulos, y luego llenar el segundo hilo en cada módulo. Cuando no lo son, puedes terminar con dos hilos pesados compartiendo un módulo mientras otro módulo está inactivo—territorio clásico de “mi CPU está al 50% pero mi servicio se está muriendo”.

Una cita que vale la pena mantener en la pared, porque así sobrevives a estas arquitecturas:
La esperanza no es una estrategia. — General Gordon R. Sullivan

Bulldozer castigó la planificación de capacidad basada en esperanza. Recompensó la medición, el pinning y los benchmarks realistas.

Ajuste de cargas: dónde Bulldozer destaca y dónde fracasa

Buenas adaptaciones (aún condicionales)

Bulldozer podía verse respetable en cargas que eran:

• altamente paralelizadas con baja sensibilidad a la latencia por hilo
• pesadas en enteros y tolerantes a la contención del front-end
• orientadas al rendimiento por lotes donde puedes sobre-suscribir y mantener la máquina ocupada
• servicios que escalan casi linealmente con más hilos ejecutables (algunas cargas web, algunas granjas de compilación)

En esos casos, el enfoque por módulos puede ofrecer trabajo decente por dólar—especialmente si lo compraste en el momento adecuado y no lo comparaste con una fantasía.

Malas adaptaciones (las que despidieron gente)

Bulldozer tendía a decepcionar en:

• cuellos de botella de un solo hilo críticos para latencia (bloqueos calientes, pausas de GC, manejadores de solicitudes de un solo hilo, puntos calientes de serialización)
• trabajo intensivo en FP/vector cuando los hilos colisionan en un módulo
• juegos y cargas interactivas donde unos pocos hilos dominan el tiempo de cuadro
• tenencia mixta donde “vecinos ruidosos” compiten por recursos compartidos del módulo de forma impredecible

Traducción: si tu negocio es “responder rápido”, Bulldozer requería más cuidado. Si tu negocio es “terminar eventualmente”, Bulldozer podía estar bien—hasta que la potencia o la temperatura se convirtieran en la siguiente limitación.

La trampa empresarial: “núcleos” como ficción de compras

A las empresas les encantan los números que puedes pegar en hojas de cálculo. “Núcleos” es uno de ellos. Bulldozer explotó esa debilidad, a veces por accidente, a veces no.

Si tu licenciamiento, capacidad o matemáticas de SLO asumen que cada “núcleo” es equivalente al “núcleo” de cualquier otro proveedor, detente.
Recalibra alrededor del rendimiento medido, no del recuento de etiquetas. Esto es cierto hoy con SMT, núcleos de eficiencia y aceleradores compartidos también. Bulldozer fue solo un recordatorio temprano y ruidoso.

La visión de un SRE: modos de fallo observables

En operaciones, no depuras microarquitectura directamente. Depuras síntomas: encolamiento, latencia de cola, profundidad de la cola de ejecución,
tiempo de robo (steal), stalls de memoria, estrangulamiento térmico, artefactos de planificación.

Síntomas con forma de Bulldozer

• Alta latencia con utilización moderada de CPU porque el trabajo “ocupado” está compitiendo en recursos compartidos del módulo.
• Variabilidad de rendimiento entre hosts idénticos debido a configuraciones BIOS, C-states, comportamiento de turbo y colocación de hilos.
• Sorpresas en virtualización cuando la topología de vCPU no coincide con la topología de módulos, causando contención evitable o fallos NUMA.
• Techos de potencia/temperatura que impiden el boost sostenido, haciendo irrelevante el “reloj nominal” en pruebas de carga de larga duración.

Segundo chiste, y eso es todo: tratar los núcleos Bulldozer como idénticos es como tratar todas las colas como FIFO—reconfortante, hasta que miras los gráficos.

Por qué los ingenieros de almacenamiento deberían importar (sí, en serio)

Las pilas de almacenamiento están llenas de trabajo de CPU: checksums, compresión, cifrado, procesamiento de red, churn de metadatos del sistema de archivos, manejo de interrupciones y orquestación en espacio de usuario. Una CPU con patrones de contención extraños puede convertir un “problema de disco” en un problema de planificación de CPU que lleva puesta la etiqueta de disco.

Si ejecutas almacenamiento en red, gateways de almacenamiento de objetos o cualquier cosa cercana a ZFS en silicio de la era Bulldozer, debes
separar “el dispositivo es lento” de “la CPU es lenta en este tipo específico de trabajo.” La solución podría ser un ajuste del scheduler, no un SSD nuevo.

Guion de diagnóstico rápido

Cuando un host de la era Bulldozer rinde menos, no empieces discutiendo sobre IPC en foros. Comienza ubicando el cuello de botella en
tres pasadas: planificación/topología, frecuencia/potencia y luego memoria/IO.

Primero: verifica la colocación de hilos y la alineación topológica

• Confirma cuántos sockets, nodos NUMA y núcleos tienes realmente.
• Revisa si los hilos calientes están empaquetados en el mismo módulo.
• En VMs, valida que la topología de vCPU presentada al invitado coincida con lo que el hipervisor puede respaldar con recursos físicos.

Segundo: confirma que no estás perdiendo por relojes (governor, turbo, térmicas)

• Comprueba la frecuencia de CPU bajo carga sostenida, no en reposo.
• Verifica que el governor esté configurado apropiadamente para cargas de servidor.
• Busca estrangulamiento térmico, límites de potencia o C-states demasiado agresivos.

Tercero: mide stalls y encolamientos (CPU vs memoria vs IO)

• Usa perf para ver si estás atascado en front-end, back-end o esperando memoria.
• Revisa la profundidad de la cola de ejecución y los cambios de contexto.
• Valida que las interrupciones de almacenamiento y red no se acumulen sobre una CPU desafortunada.

La regla de decisión: si arreglar la colocación y los relojes mejora la latencia en dos dígitos, detente ahí y estabiliza.
Si no, pasa a un perfilado más profundo.

Tareas prácticas: 12+ comprobaciones con comandos, salidas y decisiones

Estas no son “benchmarks para un blog.” Son las comprobaciones que ejecutas en una máquina que no alcanza los SLO. Cada tarea incluye:
un comando, salida de ejemplo, qué significa y qué decisión tomar.

1) Identificar modelo de CPU y topología rápidamente

cr0x@server:~$ lscpu
Architecture:            x86_64
CPU(s):                  16
Thread(s) per core:      1
Core(s) per socket:      8
Socket(s):               2
NUMA node(s):            2
Model name:              AMD Opteron(tm) Processor 6272
NUMA node0 CPU(s):       0-7
NUMA node1 CPU(s):       8-15

Qué significa: Probablemente estás en la serie Opteron 6200 (derivado de Bulldozer). Threads-per-core es 1 (sin SMT), pero los módulos aún comparten recursos.

Decisión: Trata la planificación y el pinning como críticos. También verifica la afinidad NUMA para servicios intensivos en memoria.

2) Confirmar kernel y contexto del scheduler

cr0x@server:~$ uname -r
5.15.0-94-generic

Qué significa: Kernel moderno, generalmente mejor conciencia topológica que la era 3.x temprana. Aun así: tu hipervisor, BIOS y carga pueden derrotarlo.

Decisión: No asumas que “el kernel nuevo lo solucionó.” Mide el comportamiento de la colocación con mapas reales de hilos.

3) Ver utilización por CPU para detectar empaquetamiento

cr0x@server:~$ mpstat -P ALL 1 3
Linux 5.15.0-94-generic (server)  01/21/2026  _x86_64_ (16 CPU)

12:00:01 AM  CPU   %usr  %sys  %iowait  %irq  %soft  %idle
12:00:02 AM  all   42.10  6.20   0.10   0.20  0.50  50.90
12:00:02 AM    0   88.00  8.00   0.00   0.00  0.00   4.00
12:00:02 AM    1   86.00 10.00   0.00   0.00  0.00   4.00
12:00:02 AM    2    5.00  2.00   0.00   0.00  0.00  93.00
...

Qué significa: CPU0 y CPU1 están saturadas mientras CPU2 está inactiva. Huele a empaquetamiento de hilos, problemas de afinidad de IRQ o un proceso fijado.

Decisión: Identifica el proceso y su afinidad de CPU; corrige el pinning o ajusta la distribución del scheduler/IRQ.

4) Encontrar el proceso caliente y su disposición de hilos

cr0x@server:~$ ps -eo pid,comm,%cpu --sort=-%cpu | head
  PID COMMAND         %CPU
 8421 java            175.3
 2310 ksoftirqd/0      35.0
 1023 nginx            22.4

Qué significa: Una JVM está usando ~1.75 núcleos de CPU; ksoftirqd/0 también está ocupado en CPU0. Probablemente haya contención.

Decisión: Inspecciona la colocación por hilo y la distribución de interrupciones antes de tocar flags de la JVM.

5) Inspeccionar mapeo hilo-a-CPU para el PID caliente

cr0x@server:~$ pid=8421; ps -L -p $pid -o pid,tid,psr,pcpu,comm --sort=-pcpu | head
 PID   TID  PSR  %CPU COMMAND
8421  8421    0  98.5 java
8421  8434    1  77.2 java
8421  8435    0  15.0 java
8421  8436    1  12.1 java

Qué significa: Los hilos están atascados en CPU0/CPU1. En Bulldozer, eso puede significar “dos hilos peleando dentro de un módulo” dependiendo del numerado y la topología.

Decisión: Elimina afinidades excesivamente estrictas; distribuye entre núcleos/módulos; o fija explícitamente hilos críticos entre módulos.

6) Comprobar la máscara de afinidad de CPU del proceso

cr0x@server:~$ taskset -pc 8421
pid 8421's current affinity list: 0-1

Qué significa: Alguien fijó la JVM a las CPU 0–1. Ese es el “pistolero de la optimización”.

Decisión: Expándela a un conjunto sensato (por ejemplo, repartir entre módulos o nodo NUMA), y vuelve a probar la latencia.

7) Aplicar una afinidad más segura (ejemplo) y verificar

cr0x@server:~$ sudo taskset -pc 0-7 8421
pid 8421's current affinity list: 0-7

Qué significa: El proceso ahora puede ejecutarse en las CPUs 0–7 (un nodo NUMA en este ejemplo).

Decisión: Si la carga es local en memoria, mantenla dentro de un nodo NUMA. Si es bound a CPU y con muchos hilos, considera usar ambos nodos con cuidado.

8) Comprobar el governor de frecuencia y la política actual

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Qué significa: “powersave” en un servidor bajo carga puede ser catastrófico para la latencia.

Decisión: Cambia a “performance” para servicios críticos de latencia, y luego valida térmicas y margen de potencia.

9) Cambiar el governor a performance (temporal) y verificar

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11
Setting cpu: 12
Setting cpu: 13
Setting cpu: 14
Setting cpu: 15

Qué significa: Todas las CPUs ahora apuntan a la máxima frecuencia bajo carga.

Decisión: Vuelve a ejecutar tu prueba de carga; si la latencia en cola baja, haz el cambio persistente vía tu gestión de configuración.

10) Observar la frecuencia real bajo carga

cr0x@server:~$ sudo turbostat --Summary --interval 2
turbostat: Snapshot every 2.0 sec
Avg_MHz   Busy%   Bzy_MHz  IRQ     SMI
2875      62.10   4630     1234    0

Qué significa: Las CPUs están haciendo boost (Bzy_MHz más alto que Avg_MHz). Si vieras Bzy_MHz bajo, sospecharías estrangulamiento o política.

Decisión: Si el boost colapsa durante ejecuciones sostenidas, investiga térmicas, límites de potencia en BIOS o flujo de aire del chasis.

11) Comprobar la presión de la cola de ejecución y los cambios de contexto

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0      0 812340  90212 993220    0    0     1     2 1100 4200 45  6 49  0  0
 9  0      0 811900  90212 993500    0    0     0     0 2100 9800 52  8 40  0  0

Qué significa: La cola de ejecución (r) sube a 9 en un sistema de 16 CPU; los cambios de contexto (cs) son altos. Podría ser sobre-suscripción u contención por locks.

Decisión: Si es sensible a la latencia, reduce hilos ejecutables (tamaños de pool), arregla puntos calientes de bloqueo o asegúrate de que los hilos no compitan dentro de módulos.

12) Inspeccionar localidad NUMA (colocación de memoria vs CPU)

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

Qué significa: Dos nodos NUMA. Si tu proceso corre en CPUs del nodo 0 pero asigna memoria en el nodo 1, pagas latencia remota.

Decisión: Fija proceso y memoria al mismo nodo para latencia consistente (numactl --cpunodebind/--membind), o arregla la colocación de la VM.

13) Ver si las interrupciones están concentradas en una CPU

cr0x@server:~$ cat /proc/interrupts | head -n 10
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  24:    982312          0          0          0          0          0          0          0   IO-APIC  24-fasteoi   eth0
  25:      1200        980        870        910        940        905        899        920   IO-APIC  25-fasteoi   ahci

Qué significa: Las IRQs de red llegan casi exclusivamente a la CPU0. Eso puede dejar sin recursos al trabajo real y crear contención en el módulo.

Decisión: Configura la afinidad de IRQ o verifica el comportamiento de irqbalance; para NICs de alto rendimiento, reparte colas entre CPUs y núcleos locales NUMA.

14) Comprobación rápida de latencia de almacenamiento (porque siempre lo acusan)

cr0x@server:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          44.21    0.00    6.44    0.20    0.00   49.15

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
sda              2.0   8.0   64.0  512.0   3.10   0.45   0.90

Qué significa: El disco no es el cuello de botella (await bajo, %util bajo). Tu ticket “el almacenamiento está lento” probablemente sea planificación de CPU o comportamiento de la app.

Decisión: Deja de cambiar discos. Céntrate en la colocación de CPU, IRQs y contención por locks.

15) Medir a dónde va el tiempo de CPU (enfoque top-down) con perf

cr0x@server:~$ sudo perf stat -p 8421 -a -- sleep 10
 Performance counter stats for 'system wide':

        32,145.12 msec task-clock                #    3.214 CPUs utilized
       120,331,221      context-switches          #    3.742 M/sec
         2,110,334      cpu-migrations            #   65.655 K/sec
    98,771,234,112      cycles                    #    3.070 GHz
    61,220,110,004      instructions              #    0.62  insn per cycle
     9,112,004,991      branches                  #  283.381 M/sec
       221,004,112      branch-misses             #    2.43% of all branches

Qué significa: IPC ~0.62 es bajo para muchas cargas de servidor; las migraciones y cambios de contexto son enormes, lo que sugiere agitación del scheduler.

Decisión: Reduce migraciones (afinidad/vínculo NUMA), dimensiona correctamente los pools de hilos e aisla IRQs. Luego vuelve a medir IPC y latencia.

16) Comprobar tiempo de robo en virtualización (si aplica)

cr0x@server:~$ mpstat 1 3 | tail -n 3
12:01:01 AM  all   40.20  7.10   0.10   0.20  0.50  48.40  3.50
12:01:02 AM  all   41.10  7.30   0.10   0.20  0.40  47.60  3.30
12:01:03 AM  all   39.80  6.90   0.10   0.20  0.50  49.10  3.40

Qué significa: %steal ~3–4% indica que tu VM espera por CPU física. En hosts Bulldozer, una mala colocación vCPU-a-módulo puede magnificar el dolor.

Decisión: Coordina con el equipo de hipervisor: aplica pinning de CPU alineado a módulos/nodos NUMA, reduce overcommit para inquilinos críticos de latencia.

Tres mini-historias corporativas (realistas, anonimizadas)

Mini-historia 1: El incidente causado por una suposición errónea

Una empresa SaaS mediana migró una capa de API de solo lectura desde quad-cores antiguos a servidores “de 8 núcleos” completamente nuevos. La presentación de compras decía que duplicaron cores por nodo, así que recortaron el número de nodos en un tercio. El despliegue estuvo bien durante dos horas, luego el percentil 99 de latencia se fue elevando como una fuga lenta.

El ingeniero on-call hizo lo de siempre: comprobó latencia de disco (bien), errores de red (ninguno), utilización de CPU (sorprendentemente moderada). La pista killer fue la colocación de hilos: los worker del servicio estaban fijados por una unidad systemd heredada a las CPUs 0–3 “por localidad de caché.” En este hardware, esas CPUs se mapeaban a menos módulos de lo esperado, y los hilos calientes estaban peleando por recursos front-end compartidos.

Intentaron volver a escalar—más nodos—pero el presupuesto ya estaba comprometido. Así que hicieron el trabajo aburrido: quitaron el pinning antiguo, validaron una distribución amigable con los módulos y ajustaron los conteos de workers para que coincidieran con el rendimiento real y no con núcleos etiquetados.
La latencia en cola bajó a niveles aceptables.

El postmortem no fue sobre AMD o Intel. Fue sobre una suposición: que “8 núcleos” significaba “el doble de paralelismo que 4.” En Bulldozer, la topología importa lo suficiente como para que esa suposición pueda ser operacionalmente falsa.

Mini-historia 2: La optimización que se volvió en contra

Un equipo de analítica financiera ejecutaba simulaciones Monte Carlo durante la noche. Afinaron todo: flags del compilador, huge pages, pinning de hilos, allocators de memoria hechos a mano. Alguien notó que las ejecuciones eran más rápidas cuando fijaban dos hilos worker al mismo par de módulos—menos comunicación entre módulos, razonaron. “Funcionó” en un microbenchmark y parecía genial.

Luego activaron una biblioteca matemática actualizada que usaba instrucciones vectoriales más anchas y una estrategia de hilos ligeramente diferente. Ahora, dos hilos por módulo estaban golpeando los recursos FP compartidos. El rendimiento cayó. Peor aún, se volvió ruidoso: unas noches el job terminaba antes de horario laboral, otras noches no.

El equipo reaccionó como suelen hacerlo: retocaron conteos de hilos y culparon a la librería. La solución real fue el pinning consciente de topología: mantener los hilos pesados en FP distribuidos entre módulos, y solo emparejar hilos dentro de un módulo cuando puedas probar que no contendrán la unidad compartida para tu mezcla real de instrucciones.

La lección: una optimización que depende de “comportamiento microarquitectural estable” es frágil. Bulldozer hizo visible esa fragilidad, pero la misma trampa existe en CPUs modernas con cachés compartidas, SMT y escalado de frecuencia.

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

Un equipo de plataforma interno gestionaba una flota mixta: algunos nodos Intel, otros AMD de la era Bulldozer. Tenían una regla impopular: cada cambio de capacidad requería ejecutar benchmarks específicos por carga y guardar un artefacto (gráficos, configuraciones y el kernel/BIOS exacto). Nadie quería romper la regla. Lentificó las “actualizaciones simples.”

Un equipo de producto quiso desplegar una nueva función que duplicaba el parseo JSON y añadía sobrecarga TLS. En nodos Intel estuvo bien.
En nodos Bulldozer, el uso de CPU subió y la latencia en cola empezó a tambalearse bajo pruebas de carga. Como el equipo de plataforma tenía perfiles base, pudieron ver inmediatamente la delta: más ciclos en cripto y parseo, mayor presión de ramas y peor IPC.

No compraron hardware por pánico. Separaron flotas: los nodos Bulldozer manejaron el procesamiento por lotes menos sensible a latencia; los nodos Intel la capa interactiva. También ajustaron afinidad de IRQ y governor de CPU en los Bulldozer restantes para reducir jitter. La función se lanzó a tiempo.

Nadie recibió un trofeo por “mantener benchmarks base.” Pero evitó un incidente en semana de lanzamiento. En el mundo SRE, ese es el trofeo.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: picos de latencia mientras la CPU está ~50%

Causa raíz: Hilos calientes compitiendo dentro de módulos (front-end/FP compartidos) o fijados a un conjunto estrecho de CPU.

Solución: Inspecciona la colocación de hilos (ps -L), elimina afinidades estrictas (taskset -pc), reparte hilos calientes entre módulos y reduce la agitación del scheduler.

2) Síntoma: los números de benchmark se ven bien, producción es peor

Causa raíz: Los microbenchmarks caben en caché, evitan contención FP y se ejecutan en condiciones de turbo ideales.

Solución: Usa tests de carga sostenida con conjuntos de datos representativos; mide la frecuencia a lo largo del tiempo (turbostat) y la latencia en cola, no solo el throughput.

3) Síntoma: rendimiento de VM inconsistente entre hosts

Causa raíz: La topología de vCPU no se alinea con los módulos/NUMA físicos; el overcommit y el tiempo de steal amplifican la contención por módulos.

Solución: Usa pinning a nivel host alineado con nodos NUMA; evita que VMs sensibles a la latencia compartan módulos bajo carga; monitorea %steal.

4) Síntoma: tickets de “el almacenamiento está lento”, pero los discos están inactivos

Causa raíz: Componentes de la pila de almacenamiento limitados por CPU (checksums, compresión, cripto) o concentración de IRQ en una CPU.

Solución: Valida con iostat -x y /proc/interrupts; redistribuye IRQs; considera deshabilitar funciones CPU-intensivas en esos hosts o mover la carga.

5) Síntoma: el rendimiento cae tras iniciativas de “ahorro de energía”

Causa raíz: Governor puesto en powersave, C-states profundos o políticas BIOS agresivas que reducen la frecuencia sostenida.

Solución: Configura el governor a performance para servicios críticos; audita la configuración BIOS de forma consistente en la flota; valida térmicas.

6) Síntoma: dos servidores “idénticos” se comportan distinto

Causa raíz: Diferencias en BIOS (turbo, C-states), microcódigo, población de DIMM que afecta NUMA, o enrutamiento de IRQ distinto.

Solución: Estandariza perfiles BIOS, confirma paquetes de microcódigo, compara lscpu/numactl --hardware y diff de distribuciones de interrupciones.

Listas de verificación / plan paso a paso

Al heredar una flota de la era Bulldozer (plan de la primera semana)

1. Inventario de topología: captura lscpu, numactl --hardware y versiones de kernel para cada clase de host.
2. Estandarizar BIOS y política de potencia: confirma C-states, comportamiento de turbo y cualquier límite de potencia; elige un perfil consistente.
3. Establecer y aplicar la política de governor: “performance” para capas de latencia; documenta excepciones.
4. Benchmarks base por carga: un perfil interactivo y uno por lotes; guarda salidas y configuraciones.
5. Auditar pinning de CPU: busca en tus unit files, configuraciones de contenedores y políticas de orquestación ajustes de afinidad que asuman núcleos simétricos.
6. Auditar distribución de IRQ: especialmente colas de NIC; valida con muestras de /proc/interrupts durante carga.
7. Reglas de colocación NUMA: define qué servicios van ligados a un nodo vs distribuidos; intégralo en la herramienta de despliegue.

Cuando un servicio rinde mal en Bulldozer (triaje de 60 minutos)

1. Revisa utilización por CPU (mpstat -P ALL) para detectar empaquetamiento.
2. Revisa afinidad del proceso (taskset -pc) y CPU por hilo (ps -L).
3. Revisa governor y frecuencia real (sysfs cpufreq + turbostat).
4. Revisa cola de ejecución y cambios de contexto (vmstat).
5. Revisa la topología NUMA y si estás accidentalmente remoto (numactl --hardware + política de colocación).
6. Revisa hotspots de IRQ (/proc/interrupts) y distribúyelos si es necesario.
7. Sólo entonces: perf stat para confirmar CPU-bound vs memory-bound.

Al planear una migración (qué medir antes de comprar)

1. Mide rendimiento y latencia en cola por vatio bajo carga sostenida.
2. Cuantifica cuánto tiempo pasa tu carga en FP/vector, parseo con muchas ramas o stalls de memoria.
3. Simula escenarios de “vecino ruidoso” si ejecutas cargas mixtas o virtualización.
4. Calcula licenciamiento con equivalencia de núcleos realista (o no uses núcleos—usa unidades de capacidad medidas).

Preguntas frecuentes

1) ¿Bulldozer era “realmente ocho núcleos”?

Tenía ocho núcleos enteros en las piezas comunes FX “de 8 núcleos” (cuatro módulos), pero algunos recursos clave se compartían por módulo.
Para muchas cargas, ese compartido hace que se comporte distinto a ocho núcleos totalmente independientes.

2) ¿Por qué Bulldozer perdió tan mal en algunos benchmarks de un solo hilo?

Porque el énfasis del diseño era el rendimiento total con recursos compartidos, y la eficiencia por hilo del front-end y ejecución no igualó a competidores optimizados para IPC en un solo hilo en ese momento.

3) ¿El scheduler del sistema operativo realmente importaba tanto?

Sí. La colocación de hilos que apila hilos calientes en el mismo módulo puede crear contención evitable. Un mejor comportamiento del scheduler ayuda, pero el pinning, la topología de virtualización y la colocación de IRQ siguen importando.

4) ¿Bulldozer es siempre malo para servidores?

No. Para cargas suficientemente paralelas, orientadas al throughput y mayormente enteras, puede ser aceptable. El riesgo es que muchas “cargas de servidor” tienen una cola de latencia dominada por un pequeño número de hilos.

5) ¿Cuál es la victoria operativa más simple si estoy atascado con hardware Bulldozer?

Arregla la política de frecuencia y la colocación: usa el governor correcto, verifica relojes sostenidos, elimina pinning malo y evita que las IRQ se queden en CPU0.

6) ¿Cómo sé si sufro contención por módulos específicamente?

A menudo verás alta latencia con CPU media, uso desigual por CPU, IPC bajo en perf stat y mejora al repartir hilos o reducir emparejamientos por módulo.

7) ¿Las arquitecturas AMD posteriores cuentan la misma historia?

No. Los diseños posteriores de AMD se alejaron de los compromisos de módulo de Bulldozer de formas que mejoraron dramáticamente el rendimiento por núcleo y redujeron las sorpresas por cuellos de botella compartidos. No generalices el dolor de Bulldozer a todas las CPUs AMD.

8) ¿Debo desactivar características de ahorro de energía en estos sistemas?

Para capas críticas de latencia, a menudo sí—al menos deshabilita las políticas más agresivas y usa el governor performance.
Pero valida térmicas y capacidad eléctrica; no cambies picos de latencia por estrangulamiento aleatorio.

9) ¿Importa si ejecuto contenedores en lugar de VMs?

Puede importar más. Los contenedores facilitan sobre-suscribir CPU accidentalmente y aplicar pinning ingenuo. Si tu orquestador no es consciente de la topología, puedes crear patrones de contención que parecen “lentitud misteriosa.”

10) Si compro hardware usado para un laboratorio, ¿vale la pena Bulldozer?

Para aprender sobre planificación, NUMA y diagnósticos de rendimiento, es un maestro sorprendentemente bueno. Para computación eficiente y predecible por vatio, puedes hacerlo mejor con generaciones más nuevas.

Conclusión: qué hacer a continuación en una flota real

La historia real de Bulldozer no es “AMD fracasó.” Es que las apuestas arquitectónicas audaces tienen consecuencias operacionales. Los recursos compartidos
no aparecen en una hoja de especificaciones como el recuento de núcleos, pero sí aparecen en tu línea de tiempo de incidentes.

Si aún ejecutas máquinas de la era Bulldozer, trátalas como una clase especial de hardware:
estandariza BIOS y política de frecuencia, audita pinning e IRQs y ejecuta benchmarks de las cargas que realmente ejecutas. Si planeas capacidad, deja de usar núcleos etiquetados como unidad de cómputo. Usa rendimiento medido y latencia en cola bajo carga sostenida.

Pasos prácticos siguientes, en orden:

1. Ejecuta el guion de diagnóstico rápido en un host “malo” y uno “bueno”, lado a lado.
2. Elimina pinning accidental, reparte hilos calientes y arregla hotspots de IRQ.
3. Bloquea configuraciones consistentes de potencia/frecuencia apropiadas para tus SLO.
4. Decide qué cargas pertenecen a este silicio—y mueve el resto.

Bulldozer quería un mundo donde todo fuera perfectamente paralelo. La producción no es ese mundo. La producción es desordenada, compartida,
impulsada por interrupciones y llena de pequeños cuellos de botella con disfraces. Planea en consecuencia.