AMD SMT: cuando la “función de Intel” se convirtió en un rival real

Qué es realmente SMT (y qué no es)

SMT permite que un núcleo físico presente múltiples CPUs lógicas al sistema operativo. En la mayoría de las piezas de servidor AMD modernas,
eso son 2 hilos por núcleo (SMT2). El scheduler ve dos “CPUs”. El núcleo ve un conjunto de recursos de ejecución, compartidos
entre dos estados arquitectónicos.

Esa última frase es el meollo operativo: dos hilos comparten algo. No se convierten magicamente en dos núcleos.
En la práctica, comparten recursos del front-end, unidades de ejecución, cachés en varios niveles y—críticamente—rutas de
contención que solo notas en p95/p99. SMT es una apuesta a que cuando un hilo está bloqueado (miss de caché, predicción de salto fallida, espera de memoria),
el otro hilo puede usar unidades que por otro modo estarían inactivas.

SMT no son “núcleos gratis”

El SO programará encantado dos hilos ocupados en los hermanos de un núcleo físico si se lo permites.
El rendimiento total puede subir, la latencia puede empeorar, y los gráficos de CPU informarán con suficiencia “no saturado”.
Así es como terminas con CPUs “solo” al 60% mientras tus clientes actualizan la página como si fuera 2009.

SMT es un contrato de planificación que no sabías que firmaste

Activar SMT cambia la topología que ve el SO. Cambia cómo fijas vCPUs, cómo particionas cargas de trabajo, cómo lees
“utilización de CPU” y cómo interpretas los contadores de perf. También puede cambiar el perfil de riesgo para ataques de canal lateral
y las mitigaciones que debes aplicar.

Una verdad seca: si no decides explícitamente cómo se usan los hermanos SMT, Linux decidirá por ti, y Linux optimiza
para rendimiento y equidad—a veces a costa de tu latencia de cola.

Cómo AMD hizo competitivo al SMT: de “lindo” a “creíble”

Durante mucho tiempo, “SMT” en la mente pública significó Hyper-Threading de Intel. AMD tuvo historias de multihilo antes de Zen, pero
Zen (y EPYC en particular) es donde el SMT de AMD se volvió relevante operativamente en las mismas conversaciones que Intel.

El cambio importante no fue de marketing. Fue la arquitectura encontrándose con la realidad de la plataforma: más núcleos, mejor
rendimiento por núcleo y un ecosistema de servidores que de repente tomó a AMD en serio. Cuando despliegas bastidores de EPYC, dejas de tratar
al SMT como una nota al pie. Empiezas a tratarlo como una política.

Por qué ocurrió el “rival real”

• Los recuentos de núcleos forzaron la pregunta. Con servidores de muchos núcleos, puedes elegir entre “más hilos ahora” y “más aislamiento”.
• Los planificadores maduraron. La conciencia de topología en Linux mejoró; los administradores aprendieron a respetar las relaciones entre hermanos de CPU.
• La nube lo convirtió en problema de todos. La contención multi-tenant y los efectos de vecinos ruidosos convierten al SMT en una decisión de negocio.
• La seguridad se hizo oír. SMT pasó a formar parte de los modelos de amenaza; algunas organizaciones lo desactivaron por defecto tras divulgaciones de ejecución especulativa.

El balance: el SMT de AMD no es una imitación. Es una perilla con compensaciones conocidas—pero los detalles de la topología de EPYC (eras CCD/CCX,
disposiciones NUMA, comportamiento de caché) significan que no puedes copiar y pegar las reglas de la era Intel y esperar felicidad.

Hechos e historia que puedes usar en una pizarra

Puntos de contexto concretos—útiles para explicar por qué tu plan de “solo activa SMT” necesita un plan de pruebas adjunto.

1. Intel lanzó ampliamente Hyper-Threading a inicios de los 2000. Moldeó el modelo mental de la industria sobre SMT durante años.
2. El diseño “module” de la era Bulldozer de AMD no era SMT. Compartía algunos recursos entre dos núcleos enteros; confundió a compradores y gráficos de benchmarks.
3. Zen (2017) llevó el SMT de AMD al mercado de servidores. EPYC convirtió al SMT en una expectativa por defecto en datacenters AMD.
4. Las primeras generaciones de EPYC expusieron una topología compleja. El comportamiento NUMA y los dominios de caché importaban más que “hilos por núcleo”.
5. Los planificadores de Linux mejoraron en packing y spreading. La planificación consciente de topología redujo algunas patologías clásicas de HT/SMT, pero no todas.
6. Las divulgaciones de ejecución especulativa cambiaron los valores por defecto. Tras 2018, muchas empresas revisaron políticas de SMT por riesgo de filtración entre hilos.
7. Algunos hyperscalers eligieron SMT activado para throughput y SMT desactivado para ciertos niveles. La era del “talla única” terminó.
8. Los incrementos de rendimiento por SMT dependen de la carga de trabajo. Para muchas cargas de servidor, SMT da ganancias modestas; para otras es negativo bajo contención.

Si necesitas un único modelo mental: SMT es mejor cuando un hilo deja huecos en la tubería y el otro puede llenarlos.
SMT es peor cuando ambos hilos quieren los mismos recursos calientes al mismo tiempo.

Realidad de rendimiento: dónde SMT ayuda, perjudica y te engaña

Dónde SMT suele ayudar

SMT tiende a ayudar cuando tienes mucho trabajo independiente que se bloquea con frecuencia: servicios con muchas solicitudes que esperan I/O,
flujos de instrucciones mixtos, código con muchas ramas, misses de caché y suficiente paralelismo para mantener la máquina ocupada.
Los sistemas orientados a throughput (procesamiento por lotes, algunos niveles web, consumidores de colas en background) suelen ver beneficios.

Dónde SMT a menudo perjudica

SMT puede perjudicar cuando te importa la latencia por solicitud consistente, o cuando la carga ya está muy optimizada y
satura recursos de ejecución. El hilo hermano se convierte en contención, no en ayuda.
Víctimas clásicas: sistemas tipo trading de baja latencia (aunque no seas trader), bases de datos OLTP muy ocupadas y rutas de almacenamiento
donde la contención de locks y el comportamiento de caché de la CPU importan.

La mentira: “La utilización de CPU es baja, así que la CPU no es el cuello de botella”

Con SMT, puedes tener un núcleo con dos hermanos cada uno al 50% de “utilización” mientras el núcleo físico está efectivamente saturado
en un recurso crítico. Ves tiempo inactivo porque la medición es por CPU lógica, no por recurso físico.

Si tu p99 empeora después de activar SMT, no discutas con el gráfico. Discute con el scheduler y los contadores.

Contención de recursos de la que realmente deberías preocuparte

• Presión L1/L2 y contención del front-end de instrucciones. Dos hilos calientes pelean por las mismas cosas pequeñas y rápidas.
• Unidades de ejecución compartidas. Si ambos hilos son intensivos en las mismas unidades, SMT se vuelve auto-lesivo.
• Caché y ancho de banda de memoria. SMT puede aumentar las solicitudes de memoria pendientes, lo que puede ayudar o saturar el fabric.
• Contención de locks y bucles de spin. SMT puede convertir “un poco de spinning” en “dos hilos quemando el mismo núcleo”.
• Overhead del kernel e interrupciones. Una mala colocación de IRQ junto con SMT puede inyectar jitter en tus “núcleos dedicados”.

Una cita que vale la pena tener en la pared, porque aplica a decisiones de SMT tanto como a respuesta a incidentes:
La esperanza no es una estrategia. —General James N. Mattis

La versión operativa: mide, cambia una variable y desconfía de las mejoras que solo aparecen en promedios.

Broma #1: SMT es como añadir un segundo conductor a una carretilla elevadora. A veces mueves más palés; a veces simplemente discutís más fuerte en el mismo pasillo.

Guion de diagnóstico rápido (encuentra el cuello de botella rápido)

Cuando un servicio se ralentiza y SMT está implicado, necesitas un orden de triaje determinístico. Aquí está la ruta más rápida que he encontrado
y que evita perder una tarde en impresiones subjetivas.

1) Confirma la topología y el estado de SMT

• ¿Cuántos sockets? ¿Cuántos cores por socket? ¿Está habilitado SMT?
• ¿Estás mirando “recuento de vCPU” o “núcleos físicos” en tu cálculo mental?

2) Identifica si estás limitado por throughput o por latencia

• Si p95/p99 es el dolor: asume contención/jitter hasta que se demuestre lo contrario.
• Si los backlogs de colas y el throughput total son el problema: SMT puede ayudar, pero solo si no estás saturando memoria/locks.

3) Revisa la cola de ejecución y la presión de CPU (no solo el %CPU)

• Run queue > número de núcleos físicos: la presión de planificación de CPU es real.
• Alto iowait no significa “el disco es lento”; puede significar “los hilos están bloqueados y la CPU está sin alimentar”.

4) Busca contención entre hermanos

• ¿Se co-programan dos hilos pesados en hermanos?
• ¿Las IRQs están llegando a los mismos núcleos físicos a los que has fijado cargas “críticas para latencia”?

5) Usa contadores para confirmación

• Cambios de contexto, migraciones, tasas de misses de caché, ciclos estancados.
• Compara SMT-on vs SMT-off en la misma clase de host si puedes.

6) Decide: ¿cambio de política o cambio de pinning?

• Si necesitas latencia predecible: prefiere SMT off o aislamiento estricto de hermanos.
• Si necesitas throughput y puedes tolerar jitter: prefiere SMT on con una colocación sensata.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las tareas que ejecutas durante una investigación de rendimiento o una revisión de preparación de plataforma. Cada una incluye:
comando, un fragmento de salida plausible, qué significa y qué decides a continuación.

Task 1: Check SMT enabled/disabled at the kernel interface

cr0x@server:~$ cat /sys/devices/system/cpu/smt/control
on

Significado: El kernel permite que los hermanos SMT estén en línea.

Decisión: Si estás solucionando latencias de cola, ten esto en cuenta; puedes probar off o el pinning de hermanos.

Task 2: Verify how many threads per core you actually have

cr0x@server:~$ lscpu | egrep 'Socket|Core|Thread|CPU\(s\)'
CPU(s):                               128
Thread(s) per core:                   2
Core(s) per socket:                   32
Socket(s):                            2

Significado: 64 núcleos físicos, 128 CPUs lógicas. SMT está en juego.

Decisión: Cualquier “recuento de CPU” que uses en planificación de capacidad debe ser explícito: físico vs lógico.

Task 3: Map SMT sibling pairs (who shares a core with whom)

cr0x@server:~$ for c in 0 1 2 3; do echo -n "cpu$c siblings: "; cat /sys/devices/system/cpu/cpu$c/topology/thread_siblings_list; done
cpu0 siblings: 0,64
cpu1 siblings: 1,65
cpu2 siblings: 2,66
cpu3 siblings: 3,67

Significado: CPU0 comparte un núcleo físico con CPU64, etc.

Decisión: Al fijar afinidad, trata a los hermanos como un recurso compartido. Coloca hilos pesados en núcleos diferentes, no solo en CPUs lógicas distintas.

Task 4: Confirm NUMA layout (SMT decisions are topology decisions)

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-63
node 0 size: 257842 MB
node 0 free: 198442 MB
node 1 cpus: 64-127
node 1 size: 257881 MB
node 1 free: 201113 MB

Significado: Dos nodos NUMA; en este ejemplo los límites de nodo se alinean con rangos de CPU.

Decisión: Si una app sensible a la latencia abarca nodos NUMA sin querer, corrige la colocación NUMA antes de culpar a SMT.

Task 5: Observe run queue and CPU pressure quickly

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
 9  0      0 182312  22120 913220    0    0     1    12 8420 9100 38 12 48  2  0
11  0      0 182100  22120 913224    0    0     0     0 8510 9802 44 10 44  2  0
14  0      0 181980  22120 913240    0    0     0    24 8732 10401 49 11 38  2  0

Significado: r (cola de ejecución) es alto respecto a los núcleos físicos por nodo NUMA; los cambios de contexto están elevados.

Decisión: Investiga contención de planificación y pinning. Un cs alto con SMT puede amplificar el jitter.

Task 6: Check per-CPU utilization to spot overloaded siblings

cr0x@server:~$ mpstat -P ALL 1 1 | egrep 'Average|  0 | 64 '
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %idle
Average:       0    78.20    0.00    9.10    0.20    0.00    0.40    0.00   12.10
Average:      64    72.10    0.00    8.90    0.20    0.00    0.30    0.00   18.50

Significado: Ambos hermanos de un núcleo están calientes. Ese núcleo físico probablemente está cargado de contención.

Decisión: Distribuye hilos de trabajo pesados entre núcleos físicos primero; no los empaquetes en hermanos.

Task 7: Identify CPU migration churn (bad for cache locality and latency)

cr0x@server:~$ pidstat -w 1 3
Linux 6.5.0-25-generic (server)  01/10/2026  _x86_64_  (128 CPU)

12:10:01      UID       PID   cswch/s nvcswch/s  Command
12:10:02     1001     24891    120.00     40.00  myservice
12:10:03     1001     24891    131.00     52.00  myservice
12:10:04     1001     24891    125.00     48.00  myservice

Significado: Muchos cambios de contexto voluntarios e involuntarios; posible contención o preempción.

Decisión: Si esto es crítico para latencia, considera afinidad de CPU, aislamiento por cgroup y evitar compartir hermanos SMT.

Task 8: Inspect CFS bandwidth throttling (a common “SMT made it worse” trap)

cr0x@server:~$ cat /sys/fs/cgroup/my.slice/cpu.stat
usage_usec 982331200
user_usec 811100000
system_usec 171231200
nr_periods 38122
nr_throttled 4920
throttled_usec 91822100

Significado: La carga está siendo limitada por cuota de CFS. SMT puede ocultar o empeorar esto al cambiar la capacidad percibida.

Decisión: Arregla cuotas/requests primero. La política SMT no debe compensar límites de CPU de cgroup incorrectos.

Task 9: Check IRQ distribution (interrupts stealing your “dedicated” cores)

cr0x@server:~$ head -n 10 /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  24:     90122      1021      1120      1033   PCI-MSI 524288-edge  nvme0q0
  25:     88211       998      1099      1010   PCI-MSI 524289-edge  nvme0q1
  26:     87440      1002      1111       999   PCI-MSI 524290-edge  nvme0q2

Significado: CPU0 está manejando la mayoría de las interrupciones NVMe. Si CPU0 es hermano de un trabajador crítico para latencia, disfruta de tu jitter.

Decisión: Rebalancea la afinidad de IRQ lejos de núcleos críticos; no permitas que hermanos SMT compartan CPUs con muchas IRQ.

Task 10: Verify kernel mitigations that interact with SMT/security posture

cr0x@server:~$ grep -E 'mitigations|nosmt|spectre|mds|l1tf' /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.0-25-generic root=/dev/mapper/vg0-root ro mitigations=auto

Significado: Las mitigaciones están habilitadas automáticamente; SMT no está explícitamente deshabilitado vía nosmt.

Decisión: Alinea con tu política de seguridad. Algunas organizaciones requieren SMT off; otras aceptan mitigaciones y aislamiento.

Task 11: Compare throughput and stalls with perf counters

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

   78,221,990,112      cycles
   96,311,022,004      instructions              #    1.23  insn per cycle
      221,884,110      cache-misses
        9,882,110      context-switches

      10.004178002 seconds time elapsed

Significado: IPC, misses de caché y cambios de contexto proporcionan una comprobación de cordura. Si IPC cae y los misses de caché suben tras activar SMT, estás pagando impuesto por contención.

Decisión: Si p99 está mal y IPC/cachés empeoran con SMT activado, prueba con SMT off o aplica aislamiento de hermanos.

Task 12: Check if the kernel has offline’d sibling CPUs (partial SMT disable)

cr0x@server:~$ for c in 64 65 66 67; do echo -n "cpu$c online="; cat /sys/devices/system/cpu/cpu$c/online; done
cpu64 online=1
cpu65 online=1
cpu66 online=1
cpu67 online=1

Significado: Los hermanos están en línea. Si ves 0, SMT puede estar efectivamente reducido mediante offlining de CPUs.

Decisión: Estandariza: gestiona SMT vía opciones de BIOS/kernel o vía conjuntos de CPU controlados—no dejes un estado medio configurado en una flota.

Task 13: Pin a process away from SMT siblings (quick experiment)

cr0x@server:~$ sudo taskset -cp 4-31 24891
pid 24891's current affinity list: 0-127
pid 24891's new affinity list: 4-31

Significado: El proceso está restringido a un subconjunto de CPUs (idealmente alineado con núcleos físicos).

Decisión: Si la latencia mejora, no necesariamente necesitas SMT off—necesitas mejor colocación.

Task 14: Confirm your CPU set doesn’t accidentally include sibling pairs

cr0x@server:~$ sudo cset shield --cpu=2-15 --kthread=on
cset: --> shielding CPUs: 2-15
cset: --> kthread shield set to: on

Significado: Creaste un shield de CPU (vía cpuset) para aislamiento. Pero aún necesitas asegurarte de que esas CPUs estén limpias respecto a núcleos físicos.

Decisión: Usa el mapeo de thread_siblings_list para construir cpusets que no pongan dos tareas pesadas en el mismo núcleo.

Broma #2: Apagar SMT para arreglar la latencia sin medir es como reiniciar un router para arreglar DNS—a veces funciona, y no aprendes nada.

Tres mini-historias corporativas desde las trincheras

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

Una empresa SaaS mediana migró un tier API central de servidores Intel antiguos a relucientes hosts AMD EPYC. El objetivo era simple:
reducir el coste por petición. Mantuvieron las mismas requests/limits de CPU en Kubernetes y trataron la “vCPU” como “núcleo”, porque el mundo antiguo se comportaba mayormente así.

El despliegue se veía bien en staging. En producción, la latencia p99 se duplicó bajo carga pico. Los gráficos de CPU eran aburridos: 55–65%,
nada alarmante. El equipo on-call persiguió consultas de base de datos, luego red de red, luego tuning de GC. El servicio “no estaba limitado por CPU”,
así que nadie tocó la política de CPU.

El error: asumieron que dos CPUs lógicas equivalían a dos núcleos físicos para su carga. En realidad, sus manejadores de peticiones ya estaban calientes y con muchas ramas, y habían colocado múltiples pods ocupados de forma que los hermanos competían
constantemente. Linux estaba siendo justo, y la carga estaba siendo castigada.

La solución no fue dramática. Mapearon pares de hermanos, ajustaron la política del CPU Manager para el tier de latencia y se aseguraron de que
los pods “garantizados” recibieran núcleos enteros (y no hermanos compartidos con otros pods pesados). También dejaron de interpretar
“65% CPU” como “margen”. Tras el cambio, p99 volvió cerca del baseline con throughput algo menor que la configuración empaquetada con SMT—
pero era predecible, que es por lo que pagan los clientes.

La lección: el incidente no fue “SMT de AMD es malo.” El incidente fue “no definimos qué significa CPU en nuestra plataforma.”
Una vez que te equivocas con las unidades, todos los dashboards mienten con cortesía.

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

Un equipo de plataforma de datos ejecutaba una carga mixta en grandes máquinas EPYC: un servicio de ingestión en streaming, un trabajo batch intensivo en compresión,
y una pasarela de almacenamiento. Alguien notó que el job batch solo corría de noche. Decidieron “tomar prestada” capacidad de CPU durante el día
activando SMT y aumentando el número de workers en el servicio de ingestión. ¿Más hilos, más throughput, no?

El primer día se vio bien—el throughput medio mejoró y la utilización de CPU subió. El segundo día, los dashboards orientados al cliente
empezaron a tener timeouts intermitentes. No constantemente. Lo suficiente como para ser exasperante. La pasarela de almacenamiento tuvo picos
de latencia esporádicos, del tipo que no aparecen en promedios pero arruinan cualquier cosa con timeouts.

Causa raíz: los hilos extras del servicio de ingestión estaban cayendo en hermanos SMT de los trabajadores críticos de la pasarela. La pasarela
tenía ráfagas periódicas intensivas en CPU (checksums, cifrado, churn de metadatos). Bajo contención SMT, esas ráfagas se alargaron,
y el encolamiento se cascada. El sistema no falló ruidosamente; falló como una burocracia—lento, inconsistente e imposible de culpar a una métrica.

El rollback restauró la estabilidad. Luego reintrodujeron el cambio correctamente: aislaron la pasarela a núcleos físicos enteros, movieron ingestión a otros núcleos,
y limitaron workers de ingestión basándose en ancho de banda de memoria y contención de locks en lugar de “hilos disponibles”.

La lección: ganancias de throughput que se roban de la latencia de cola no son victorias. SMT es un trato de hardware compartido; si no fijas límites,
él los fijará por ti, y mal.

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

Un equipo de servicios financieros ejecutaba dos clases de nodos: propósito general y sensibles a latencia. Su política era poco glamurosa: SMT activado para propósito general, SMT desactivado (o aislamiento de hermanos) para nodos de latencia. Cada cambio requería una prueba A/B con reproducción de carga fija, contadores perf capturados y una puerta de aceptación en p99.

Durante una actualización mayor del SO, un cambio de kernel ajustó el comportamiento del scheduler lo suficiente como para que algunas cargas empezaran a migrar más
agresivamente entre CPUs. La diferencia fue sutil; la mayoría de dashboards no la notaron. Pero las pruebas de aceptación de latencia sí.
Antes de que el cambio llegara a producción completa, el equipo marcó una regresión de p99 en la clase de latencia.

No discutieron teoría. Compararon estadísticas perf, tasas de cambios de contexto y conteos de migración entre los kernels viejo y nuevo, luego fijaron
el servicio crítico más estrictamente y ajustaron la afinidad de IRQ. La actualización procedió sin un incidente visible para el cliente.

La lección: las “puertas aburridas” y las pruebas repetibles vencen a la astucia. SMT interactúa con schedulers, kernels y microcódigo.
Si no tienes un arnés, no tienes control—tienes esperanza.

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

1) Síntoma: p99 picos de latencia tras activar SMT, pero %CPU se ve bien

Causa raíz: Dos hilos calientes co-programados en hermanos SMT; la utilización de CPU lógica oculta la contención física.

Solución: Fija afinidad de los trabajadores críticos a núcleos físicos enteros o aísla hermanos; valida con mapeo de siblings y contadores perf.

2) Síntoma: “Más vCPUs” en VMs no aumentó el throughput

Causa raíz: Los vCPUs cayeron en hermanos o núcleos sobresuscritos; el host está limitado por contención (caché/memoria/locks).

Solución: Usa pinning de CPU con conciencia de hermanos; reduce el recuento de vCPU para VMs críticas para que coincidan con núcleos físicos; mide run queue e IPC.

3) Síntoma: Pods Guaranteed en Kubernetes siguen mostrando jitter

Causa raíz: Los CPUs exclusivos no eran realmente exclusivos—se compartieron hermanos con otras cargas, o las IRQs aterrizaron en los mismos núcleos.

Solución: Usa CPU Manager estático con asignación de núcleos enteros y asegúrate de que la afinidad de IRQ evita esos núcleos.

4) Síntoma: Desactivar SMT mejoró latencia pero hundió demasiado el throughput

Causa raíz: Usaste SMT como política global en lugar de colocación por tiers; algunas cargas se benefician de SMT y otras no.

Solución: Separa pools de nodos: SMT-on para tiers de throughput, SMT-off o aislamiento de hermanos para tiers de latencia. No mezcles sin pinning explícito.

5) Síntoma: Alto cambio de contexto y migraciones, rendimiento inestable

Causa raíz: Churn del scheduler amplificado por demasiados hilos ejecutables y sin restricciones de afinidad; SMT incrementa la superficie de planificación.

Solución: Reduce conteos de hilos worker; fija o restringe conjuntos de CPU; revisa throttling de cgroup; ajusta colocación de IRQ.

6) Síntoma: El equipo de seguridad exige SMT off “en todas partes”

Causa raíz: Política reaccionando al riesgo de canal lateral entre hilos; ingeniería no proporcionó una alternativa con niveles de riesgo.

Solución: Define tiers de carga y límites de aislamiento; para cargas multi-tenant o de alto riesgo, SMT off puede ser correcto. Para hosts dedicados, SMT on puede ser aceptable.

7) Síntoma: Nodos de almacenamiento muestran acantilados periódicos de latencia

Causa raíz: Tormentas de interrupciones o hilos del kernel compitiendo con hilos de la app en los mismos núcleos físicos; los hermanos SMT se ven afectados.

Solución: Audita /proc/interrupts, rebalancea IRQs, reserva núcleos para rutas de I/O y evita fijar trabajadores a hermanos con mucho IRQ.

Listas de verificación / plan paso a paso

Checklist A: Decidir si SMT debe estar habilitado en una clase de nodos

1. Clasifica la carga. ¿Tier de throughput o tier de latencia? Si no puedes responder, por defecto es tier de latencia.
2. Mide la línea base. Captura p50/p95/p99, tasas de error, run queue, IPC, misses de caché.
3. Cambia una cosa. Alterna SMT o aplica aislamiento de hermanos—no ambas al mismo tiempo.
4. Vuelve a ejecutar la misma carga. Reproduce tráfico de producción o usa una carga sintética estable.
5. Aprueba en p99 y señales de saturación. Los promedios no pueden aprobar la política de la plataforma.
6. Documenta el significado de “CPU”. En cuotas, modelos de capacidad y paneles: lógico vs físico.

Checklist B: Desplegar cambios de política SMT de forma segura

1. Elige una sola clase de host y una sola región/cluster.
2. Activa métricas detalladas del host: por-CPU, run queue, migraciones, distribución de IRQ.
3. Canary con un pequeño porcentaje y compara cohortes.
4. Verifica la colocación de planificación: que los hermanos no estén doble-reservados para servicios críticos.
5. Valida postura de seguridad: mitigaciones, cmdline de kernel, aprobación de cumplimiento.
6. Plan de rollback: ajuste de BIOS o parámetro de kernel, y automatización para asegurar el estado deseado.

Checklist C: Si mantienes SMT activado, exige higiene de hermanos

1. Mapea pares de hermanos una vez por plataforma y guárdalo en el inventario metadata.
2. Fija cargas críticas a núcleos físicos, no a IDs de CPU arbitrarios.
3. Separa CPUs con muchas IRQ de los núcleos de latencia.
4. Limita cargas ruidosas por cgroups/quotas, y valida que no estás estrangulando tus pods “importantes”.
5. Prueba bajo contención, no solo bajo carga media.

Preguntas frecuentes

1) ¿SMT de AMD es básicamente lo mismo que Hyper-Threading de Intel?

Conceptualmente sí: dos hilos hardware comparten los recursos de ejecución de un núcleo físico. Operativamente, aún debes
tratar a los hermanos como capacidad compartida. Las diferencias aparecen en la topología, el comportamiento de caché/fabric y los valores por defecto de la plataforma.

2) ¿Debo desactivar SMT en AMD EPYC para bases de datos?

Si ejecutas OLTP sensible a latencia y p99 importa, prueba SMT off o aislamiento estricto de hermanos. Si ejecutas consultas analíticas orientadas a throughput, SMT puede ayudar.
No decidas por oídas—decide por p99 y contadores.

3) ¿Por qué la utilización de CPU se ve más baja con SMT activado?

Porque la utilización se reporta por CPU lógica. Dos hermanos al 50% pueden aún significar que el núcleo físico está completamente en contención.
Usa run queue, IPC y métricas de latencia para interpretar “margen”.

4) ¿Puedo mantener SMT activado y obtener latencia predecible?

A veces. La jugada es aislamiento: fija las cargas críticas a núcleos físicos y mantén a los vecinos ruidosos fuera de los hilos hermanos.
También mantén las IRQ lejos de esos núcleos. Esto es más difícil que “SMT off”, pero preserva throughput para otros tiers.

5) ¿Cuál es la forma más rápida de ver pares de hermanos SMT en Linux?

Lee /sys/devices/system/cpu/cpu*/topology/thread_siblings_list. Es autorizada para cómo el kernel ve los grupos de hermanos.

6) ¿SMT aumenta el riesgo de seguridad?

SMT puede aumentar la exposición a ciertos ataques de canal lateral entre hilos porque dos hilos comparten recursos del núcleo. Muchas organizaciones
manejan esto desactivando SMT para cargas multi-tenant o de alto riesgo, mientras lo mantienen en hosts dedicados con mitigaciones.

7) En Kubernetes, ¿por qué los pods “Guaranteed” todavía compiten?

Porque “Guaranteed” normalmente significa que obtienes CPUs lógicas dedicadas, no necesariamente núcleos físicos dedicados.
Si otra carga aterriza en el hermano, aún compartes el núcleo. Usa CPU Manager estático y asignación consciente de la topología.

8) ¿Cómo decido entre “SMT off” y “pinning/aislamiento”?

Si tienes la madurez operativa para hacer cumplir pinning y monitorizar desviaciones, el aislamiento suele ser mejor para flotas mixtas.
Si necesitas predictibilidad simple y robusta para un tier dedicado, SMT off es una política limpia.

9) ¿Por qué al activar SMT aumentaron los cambios de contexto?

Más CPUs lógicas pueden aumentar las oportunidades de planificación y patrones de migración, especialmente si también incrementaste el número de workers.
A menudo la solución es menos hilos, mejor afinidad y evitar sobre-suscripción.

Conclusión: qué hacer el lunes por la mañana

AMD SMT dejó de ser una “función tipo Intel” en el momento en que EPYC se convirtió en una opción de producción seria. Trátalo como una política de plataforma,
no como una trivia de BIOS. SMT puede comprarte throughput, pero te cobrará con gusto en latencia de cola si dejas que hilos pesados se amontonen en hermanos.

Próximos pasos que realmente mueven la aguja:

1. Inventaría tu flota: estado de SMT, cores/sockets, disposición NUMA. Haz “físico vs lógico CPU” explícito en los paneles.
2. Elige un servicio crítico para latencia y ejecuta un experimento controlado SMT-on vs SMT-off con carga idéntica.
3. Si SMT permanece activado, aplica higiene de hermanos: pinning, conjuntos de CPU y afinidad de IRQ que respeten núcleos físicos.
4. Escribe la política: qué clases de nodos tienen SMT-on, cuáles SMT-off y qué puertas de aceptación deciden cambios.

Si tomas solo una idea: SMT no se trata de ganar benchmarks. Se trata de elegir dónde quieres que ocurra la contención—y luego hacer cumplir esa elección.