AMD SMT : quand la « fonctionnalité Intel » est devenue un vrai rival

Ce qu’est vraiment le SMT (et ce qu’il n’est pas)

Le SMT permet à un cœur physique de présenter plusieurs CPU logiques au système d’exploitation. Sur la plupart des processeurs serveur AMD modernes,
il s’agit de 2 threads par cœur (SMT2). L’ordonnanceur voit deux « CPU ». Le cœur voit un seul ensemble de ressources d’exécution, partagé
entre deux états architecturaux.

Cette dernière phrase est le point crucial opérationnel : deux threads partagent quelque chose. Ils ne deviennent pas magiquement deux cœurs.
En pratique, ils partagent les ressources du front-end, les unités d’exécution, les caches à divers niveaux, et — de façon critique — des chemins de contention
que vous ne remarquez qu’au p95/p99. Le SMT est un pari : quand un thread est bloqué (miss de cache, mauvaise prédiction de branchement, attente mémoire),
l’autre thread peut utiliser des unités autrement inactives.

Le SMT n’est pas des « cœurs gratuits »

L’OS planifiera volontiers deux threads chargés sur les CPU frères d’un même cœur physique si vous le laissez faire.
Le débit peut augmenter, la latence peut se dégrader, et les graphes CPU rapporteront fièrement « pas saturé ».
C’est ainsi que vous vous retrouvez avec des CPU « seulement » à 60 % d’utilisation alors que vos clients rafraîchissent la page comme en 2009.

Le SMT est un contrat d’ordonnancement que vous n’avez pas signé consciemment

Activer le SMT change la topologie que voit l’OS. Cela modifie la façon dont vous épinglez les vCPU, dont vous partitionnez les charges, dont vous lisez
« l’utilisation CPU », et dont vous interprétez les compteurs perf. Cela peut aussi changer le profil de risque pour les attaques par canaux auxiliaires
et les atténuations à déployer.

Une vérité sèche : si vous ne décidez pas explicitement comment utiliser les frères SMT, Linux décidera pour vous, et Linux optimise
pour le débit et l’équité — parfois au détriment de votre latence en queue.

Comment AMD a rendu le SMT compétitif : de « mignon » à « crédible »

Pendant longtemps, « SMT » dans l’esprit du public signifiait Hyper-Threading d’Intel. AMD avait des histoires de multithreading avant Zen, mais
Zen (et EPYC en particulier) est l’endroit où le SMT d’AMD est devenu pertinent opérationnellement dans les mêmes conversations que Intel.

Le changement important n’était pas marketing. C’était l’architecture qui rencontrait la réalité de la plateforme : des nombres de cœurs plus élevés, de meilleures performances par cœur,
et un écosystème serveur qui a soudainement pris AMD au sérieux. Quand vous déployez des racks d’EPYC, vous arrêtez de traiter
le SMT comme une note de bas de page. Vous commencez à le traiter comme une politique.

Pourquoi un « vrai rival » est apparu

• Le nombre de cœurs a posé la question. Avec des serveurs multi-cœurs, vous pouvez choisir entre « plus de threads maintenant » et « plus d’isolation ».
• Les ordonnanceurs ont mûri. La conscience de la topologie dans Linux s’est améliorée ; les administrateurs ont appris à respecter les relations entre frères CPU.
• Le cloud a rendu cela problématique pour tous. La contention multi-tenant et les effets de voisins bruyants font du SMT une décision métier.
• La sécurité est devenue un facteur. Le SMT fait désormais partie des modèles de menace ; certaines organisations l’ont désactivé par défaut après les divulgations sur l’exécution spéculative.

En résumé : le SMT d’AMD n’est pas une copie. C’est un réglage significatif avec des compromis familiers — mais les détails de la topologie EPYC (ères CCD/CCX,
dispositions NUMA, comportement des caches) font que vous ne pouvez pas copier-coller les règles de l’époque Intel et espérer être heureux.

Faits et histoire utiles pour un tableau blanc

Points de contexte concrets — utiles pour expliquer pourquoi votre plan « activez juste le SMT » doit être accompagné d’un plan de test.

1. Intel a largement déployé l’Hyper-Threading au début des années 2000. Cela a façonné le modèle mental de l’industrie autour du SMT pendant des années.
2. Le design « module » de l’ère Bulldozer d’AMD n’était pas du SMT. Il partageait certaines ressources entre deux cœurs entiers ; cela a embrouillé acheteurs et graphiques de benchmarks.
3. Zen (2017) a apporté le SMT AMD grand public aux serveurs. EPYC a fait du SMT une attente par défaut dans les datacenters AMD.
4. Les premières générations d’EPYC exposaient une topologie complexe. Le comportement NUMA et les domaines de cache importaient plus que « threads par cœur ».
5. Les ordonnanceurs Linux se sont améliorés pour le packing et le spreading. La planification consciente de la topologie a réduit certaines pathologies classiques HT/SMT, mais pas toutes.
6. Les divulgations sur l’exécution spéculative ont modifié les valeurs par défaut. Après 2018, de nombreuses entreprises ont réexaminé leurs politiques SMT à cause des risques de fuite inter-threads.
7. Certaines hyperscalers ont choisi SMT activé pour le débit, désactivé pour certains niveaux. L’ère du « taille unique » est terminée.
8. Les gains de performance dus au SMT sont spécifiques à la charge. Pour beaucoup de charges serveur, le SMT apporte des gains de débit modestes ; pour d’autres, il est négatif sous contention.

Si vous avez besoin d’un seul modèle mental : le SMT est optimal quand un thread laisse des bulles dans le pipeline et que l’autre peut les remplir.
Le SMT est pire quand les deux threads veulent les mêmes ressources chaudes en même temps.

Réalité de performance : où le SMT aide, nuit, et vous trompe

Où le SMT aide généralement

Le SMT a tendance à aider quand vous avez beaucoup de travail indépendant qui se bloque fréquemment : services à forte charge de requêtes avec attentes I/O,
flux d’instructions mixtes, code riche en branches, miss de cache, et suffisamment de parallélisme pour maintenir la machine occupée.
Les systèmes orientés débit (traitement par lots, certains niveaux web, consommateurs de files d’attente en arrière-plan) voient souvent des bénéfices.

Où le SMT nuit souvent

Le SMT peut nuire quand vous tenez à une latence par requête cohérente, ou quand la charge est déjà fortement optimisée et
sature les ressources d’exécution. Le thread frère devient une contention, pas une aide.
Victimes classiques : systèmes proches du trading à faible latence (même si vous ne tradez pas), bases OLTP chargées, et chemins de stockage
où la contention des verrous et le comportement des caches CPU comptent.

Le mensonge : « l’utilisation CPU est faible, donc le CPU n’est pas le goulot »

Avec le SMT, un cœur peut avoir deux frères à 50 % d’« utilisation » chacun alors que le cœur physique est effectivement saturé
sur une ressource critique. Vous voyez du temps idle parce que la mesure se fait par CPU logique, pas par ressource physique.

Si votre p99 se détériore après avoir activé le SMT, ne discutez pas le graphique. Discutez l’ordonnanceur et les compteurs.

Contentions de ressources auxquelles vous devriez vraiment prêter attention

• Pression L1/L2 et contention du front-end d’instructions. Deux threads chauds se battent pour les mêmes petites ressources rapides.
• Unités d’exécution partagées. Si les deux threads sollicitent fortement les mêmes types d’unités, le SMT devient auto-destructeur.
• Cache et bande passante mémoire. Le SMT peut augmenter les requêtes mémoire en vol, ce qui peut aider ou saturer l’interconnect.
• Contention des verrous et boucles de spin. Le SMT peut transformer « un peu de spinning » en « deux threads brûlant le même cœur ».
• Surcharge du noyau et interruptions. Un mauvais placement des IRQ combiné au SMT peut injecter du jitter dans vos cœurs « dédiés ».

Une citation à garder au mur, parce qu’elle s’applique aux décisions SMT autant qu’à la réponse à incidents :
Espérer n’est pas une stratégie. — Général James N. Mattis

La version opérationnelle : mesurez, changez une variable, et soyez méfiant des améliorations qui n’apparaissent que dans les moyennes.

Blague n°1 : le SMT, c’est comme ajouter un second conducteur à un chariot élévateur. Parfois vous déplacez plus de palettes ; parfois vous criez juste plus fort dans la même allée.

Guide de diagnostic rapide (trouver le goulot vite)

Quand un service ralentit et que le SMT est impliqué, vous avez besoin d’un ordre de triage déterministe. Voici le chemin le plus rapide que j’ai trouvé
pour éviter de perdre un après-midi à des impressions subjectives.

1) Confirmer la topologie et l’état du SMT

• Combien de sockets ? Combien de cœurs par socket ? Le SMT est-il activé ?
• Dans vos calculs mentaux, regardez-vous le « nombre de vCPU » ou les « cœurs physiques » ?

2) Identifier si vous êtes lié par le débit ou la latence

• Si p95/p99 fait mal : supposez contention/jitter jusqu’à preuve du contraire.
• Si les arriérés de files et le débit total posent problème : le SMT peut aider, mais seulement si vous ne saturez pas la mémoire/les verrous.

3) Vérifier la file d’exécution et la pression CPU (pas seulement le % CPU)

• File d’exécution > nombre de cœurs physiques : la pression d’ordonnancement est réelle.
• Un iowait élevé ne signifie pas « le disque est lent » ; cela peut signifier « les threads sont bloqués et le CPU est sous-alimenté ».

4) Chercher la contention entre frères

• Deux threads lourds sont-ils co-planifiés sur des frères ?
• Les IRQ frappent-ils les mêmes cœurs physiques sur lesquels vous avez épinglé des charges « critiques pour la latence » ?

5) Utiliser des compteurs pour confirmer

• Switchs de contexte, migrations, taux de cache-miss, cycles bloqués.
• Comparez SMT activé vs SMT désactivé sur la même classe d’hôte si possible.

6) Décider : changement de politique ou changement de placement ?

• Si vous avez besoin d’une latence prévisible : préférez SMT désactivé ou une isolation stricte des frères.
• Si vous avez besoin de débit et pouvez tolérer du jitter : préférez SMT activé avec un placement raisonné.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les tâches à exécuter lors d’une investigation de performance ou d’une revue de readiness plateforme. Chacune inclut :
la commande, un extrait plausible de sortie, ce que cela signifie, et ce que vous décidez ensuite.

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

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

Signification : Le noyau autorise les frères SMT en ligne.

Décision : Si vous dépannez une latence en queue, gardez cela en tête ; vous pourrez tester off ou l’épinglage des frères.

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

Signification : 64 cœurs physiques, 128 CPU logiques. Le SMT est en jeu.

Décision : Tout « compte CPU » que vous utilisez en capacity planning doit être explicite : physique vs logique.

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

Signification : CPU0 partage un cœur physique avec CPU64, etc.

Décision : Lors de l’épinglage, traitez les frères comme une ressource partagée. Placez les threads lourds concurrents sur des cœurs différents, pas seulement sur différents CPU logiques.

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

Signification : Deux nœuds NUMA ; dans cet exemple, les frontières de nœud alignent les plages CPU.

Décision : Si une application sensible à la latence s’étend involontairement sur des nœuds NUMA, corrigez le placement NUMA avant d’accuser le 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

Signification : r (run queue) est élevé par rapport aux cœurs physiques par nœud NUMA ; les switches de contexte sont relevés.

Décision : Enquêter sur la contention d’ordonnancement et l’épinglage. Un cs élevé avec le SMT peut amplifier le 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

Signification : Les deux frères d’un même cœur sont chauds. Ce cœur physique est probablement sujet à contention.

Décision : Éparpillez d’abord les threads travailleurs lourds sur des cœurs physiques ; ne les empaquetez pas sur des frères.

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

Signification : Beaucoup de switches de contexte volontaires et involontaires ; contention ou préemption possible.

Décision : Si c’est critique pour la latence, envisagez l’affinité CPU, l’isolation via cgroup, et évitez le partage avec des frères 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

Signification : La charge est limitée par le quota CFS. Le SMT peut cacher ou aggraver ce phénomène en changeant la capacité perçue.

Décision : Corrigez quotas/requests d’abord. La politique SMT ne doit pas compenser des limites de cgroup mal configurées.

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

Signification : CPU0 gère la plupart des interruptions NVMe. Si CPU0 est frère d’un travailleur critique en latence, bon courage pour votre jitter.

Décision : Rééquilibrez l’affinité des IRQ loin des cœurs critiques ; ne laissez pas des frères SMT partager des CPU chargés en 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

Signification : Les atténuations sont activées automatiquement ; le SMT n’est pas explicitement désactivé via nosmt.

Décision : Alignez-vous sur la politique sécurité. Certaines organisations exigent SMT désactivé ; d’autres acceptent les atténuations et l’isolation.

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

Signification : IPC, cache misses et switches de contexte fournissent un contrôle de validité. Si l’IPC chute et que les cache-misses augmentent après activation du SMT, vous payez une taxe de contention.

Décision : Si le p99 est mauvais et que l’IPC/les caches se dégradent avec le SMT activé, testez SMT désactivé ou imposez l’isolation des frères.

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

Signification : Les frères sont en ligne. Si vous voyez 0, le SMT peut être effectivement réduit via l’offline de CPU.

Décision : Standardisez : gérez soit le SMT via le BIOS/paramètres noyau soit via des ensembles de CPU contrôlés — ne laissez pas un état à moitié configuré sur une flotte.

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

Signification : Le processus est restreint à un sous-ensemble de CPU (idéalement aligné sur des cœurs physiques).

Décision : Si la latence s’améliore, vous n’avez pas forcément besoin de désactiver le SMT — vous avez besoin d’un meilleur placement.

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

Signification : Vous avez créé un bouclier CPU (via cpuset) pour l’isolation. Mais vous devez quand même vous assurer que ces CPU sont propres aux cœurs physiques.

Décision : Utilisez la cartographie thread_siblings_list pour construire des cpusets qui n’affectent pas deux tâches lourdes sur le même cœur.

Blague n°2 : désactiver le SMT pour corriger la latence sans mesurer, c’est comme redémarrer un routeur pour réparer le DNS — parfois ça marche, et vous n’apprenez rien.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a migré une couche API centrale d’anciens serveurs Intel vers de brillants hôtes AMD EPYC. L’objectif était simple :
réduire le coût par requête. Ils ont gardé les mêmes requests/limits Kubernetes et ont traité le « vCPU » comme un « cœur », parce que l’ancien
monde se comportait majoritairement ainsi.

Le déploiement semblait correct en staging. En production, la latence p99 a doublé sous charge maximale. Les graphes CPU étaient ennuyeux : 55–65 %,
rien d’alarmant. L’équipe on-call a chassé les requêtes base de données, puis le réseau, puis l’optimisation du GC. Le service « n’était pas limité par le CPU »,
donc personne n’a touché à la politique CPU.

L’erreur : ils ont supposé que deux CPU logiques équivalaient à deux cœurs physiques pour leur charge. En réalité, leurs
gestionnaires de requêtes étaient déjà gourmands en CPU et riches en branches, et ils avaient placé plusieurs pods chargés de sorte que les frères se concurrençaient
constamment. Linux agissait équitablement, et la charge était punie.

La correction n’a pas été dramatique. Ils ont cartographié les paires de frères, ajusté la politique du CPU Manager pour le niveau latence, et ont assuré que
les pods « guaranteed » recevaient des cœurs entiers (et non des frères partagés avec d’autres pods lourds). Ils ont aussi cessé d’interpréter
« 65 % CPU » comme « marge ». Après le changement, le p99 est revenu proche de la baseline avec un débit légèrement inférieur à la configuration empaquetée SMT —
mais c’était prévisible, ce pourquoi les clients paient.

La leçon : l’incident n’était pas « le SMT AMD est mauvais ». L’incident était « nous n’avons pas défini ce que signifie un CPU dans notre plateforme ».
Quand vous vous trompez sur les unités, chaque dashboard ment poliment.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe plateforme de données exécutait une charge mixte sur de grands serveurs EPYC : un service d’ingestion en streaming, un job batch intensif en compression,
et une passerelle de stockage. Quelqu’un a remarqué que le job batch ne tournait que la nuit. Ils ont décidé de « emprunter » de la capacité CPU pendant la journée
en activant le SMT et en augmentant le nombre de workers sur le service d’ingestion. Plus de threads, plus de débit, non ?

Le premier jour semblait excellent — le débit moyen s’est amélioré et l’utilisation CPU a augmenté. Le deuxième jour, les tableaux de bord clients
ont commencé à afficher des timeouts intermittents. Pas constamment. Juste assez pour être exaspérant. La passerelle de stockage a eu des pics de latence sporadiques,
du type qui n’apparaissent pas dans les moyennes mais détruisent tout ce qui a des timeouts.

Cause racine : les threads supplémentaires de l’ingest atterrissaient sur des frères SMT des workers critiques de la passerelle. La passerelle connaissait des
rafales CPU périodiques (checksums, chiffrement, churn des métadonnées). Sous contention SMT, ces rafales se sont allongées,
et l’enchaînement de mise en file d’attente a cascades. Le système n’a pas échoué bruyamment ; il a échoué comme une bureaucratie — lent, incohérent, et impossible à imputer à une métrique seule.

Le rollback a rétabli la stabilité. Puis ils ont réintroduit le changement correctement : isolation de la passerelle sur des cœurs physiques entiers, déplacement de l’ingest vers d’autres cœurs,
et limitation des workers d’ingest basée sur la bande passante mémoire et la contention des verrous plutôt que sur le nombre de « threads disponibles ».

La leçon : les gains de débit qui volent la latence extrême ne sont pas des victoires. Le SMT implique du matériel partagé ; si vous ne définissez pas de limites, il les définira pour vous, mal.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers exploitait deux classes de nœuds de calcul : généraliste et sensible à la latence. Leur politique était peu glamour : SMT activé pour le généraliste, SMT désactivé (ou isolation des frères) pour les nœuds latence. Chaque changement nécessitait un test A/B avec une relecture de charge fixe, des compteurs perf capturés, et une porte d’acceptation p99.

Lors d’une mise à jour majeure du noyau, un changement de planificateur a ajusté suffisamment le comportement d’ordonnancement pour que certaines charges commencent à migrer plus agressivement entre CPU. La différence était subtile ; la plupart des tableaux de bord ne l’ont pas remarquée. Mais les tests d’acceptation de latence l’ont fait.
Avant que le changement n’atteigne la production complète, l’équipe a signalé une régression p99 sur la classe latence.

Ils n’ont pas débattu la théorie. Ils ont comparé les stats perf, les taux de context switch, et les comptes de migration entre les anciens et nouveaux noyaux, puis ont épinglé le service critique plus fermement et ajusté l’affinité IRQ. La mise à jour s’est déroulée sans incident visible côté client.

La leçon : des « portes ennuyeuses » et des tests répétables battent l’ingéniosité. Le SMT interagit avec les ordonnanceurs, les noyaux et le microcode.
Si vous n’avez pas de harnais, vous n’avez pas de contrôle — vous avez de l’espoir.

Erreurs fréquentes : symptôme → cause racine → correction

1) Symbole : pics de latence p99 après activation du SMT, mais le %CPU semble correct

Cause racine : Deux threads chauds co-planifiés sur des frères SMT ; l’utilisation CPU logique masque la contention physique.

Correction : Épinglez les workers critiques en latence sur des cœurs physiques entiers ou isolez les frères ; validez avec la cartographie des frères et les compteurs perf.

2) Symbole : « Plus de vCPU » dans des VM n’a pas augmenté le débit

Cause racine : Les vCPU ont atterri sur des frères ou des cœurs sur-souscrits ; l’hôte est limité par la contention (cache/mémoire/verrous).

Correction : Utilisez l’épinglage CPU avec conscience des frères ; réduisez le nombre de vCPU pour correspondre aux cœurs physiques pour les VM critiques ; mesurez la file d’exécution et l’IPC.

3) Symbole : les pods Kubernetes Guaranteed montrent encore du jitter

Cause racine : Les CPUs exclusifs n’étaient pas vraiment exclusifs — des frères étaient partagés avec d’autres charges, ou des IRQ atterrissaient sur les mêmes cœurs.

Correction : Utilisez le CPU Manager statique avec allocation de cœurs entiers et assurez-vous que l’affinité des IRQ évite ces cœurs.

4) Symbole : désactiver le SMT a amélioré la latence mais fait chuter le débit trop fort

Cause racine : Vous avez utilisé le SMT comme politique globale plutôt que comme placement par tiers ; certaines charges bénéficient du SMT et d’autres non.

Correction : Divisez les pools de nœuds : SMT activé pour les niveaux débit, SMT désactivé ou isolation des frères pour les niveaux latence. Ne mélangez pas sans épinglage explicite.

5) Symbole : taux élevé de context switches et migrations, performance instable

Cause racine : Churn de l’ordonnanceur amplifié par trop de threads exécutables et absence de contraintes d’affinité ; le SMT augmente la surface d’ordonnancement.

Correction : Réduisez le nombre de threads workers ; épinglez ou contraignez les ensembles CPU ; vérifiez le throttling cgroup ; ajustez le placement des IRQ.

6) Symbole : l’équipe sécurité exige SMT désactivé « partout »

Cause racine : Politique réagissant au risque d’attaque par canaux inter-threads ; l’ingénierie n’a pas proposé d’alternative par niveau de risque.

Correction : Définissez des classes de charges et des limites d’isolation ; pour les charges multi-tenant ou à haut risque, SMT désactivé peut être correct. Pour des hôtes dédiés, SMT activé peut être acceptable.

7) Symbole : nœuds de stockage montrent des falaises de latence périodiques

Cause racine : Tempêtes d’interruptions ou threads noyau en contention avec des threads applicatifs sur les mêmes cœurs physiques ; les frères SMT subissent l’impact.

Correction : Auditez /proc/interrupts, rééquilibrez les IRQ, réservez des cœurs pour les chemins IO, et évitez d’épingler des workers applicatifs sur des frères chargés en IRQ.

Check-lists / plan pas à pas

Checklist A: Décider si le SMT doit être activé sur une classe de nœuds

1. Classifiez la charge. Tier débit ou tier latence ? Si vous ne pouvez pas répondre, par défaut considérez latence.
2. Mesurez la baseline. Capturez p50/p95/p99, taux d’erreur, file d’exécution, IPC, cache-misses.
3. Changez une chose. Basculez le SMT ou imposez l’isolation des frères — pas les deux en même temps.
4. Relancez la même charge. Rejouez le trafic de production ou utilisez une charge synthétique stable.
5. Validez sur p99 et signaux de saturation. Les moyennes ne sont pas autorisées à approuver une politique plateforme.
6. Documentez la signification de « CPU ». Dans les quotas, les modèles de capacité et les dashboards : logique vs physique.

Checklist B: Déployer des changements de politique SMT en toute sécurité

1. Choisissez une seule classe d’hôte et une seule région/cluster.
2. Activez des métriques hôtes détaillées : par-CPU, file d’exécution, migrations, distribution des IRQ.
3. Canarisez avec un petit pourcentage et comparez les cohortes.
4. Vérifiez le placement d’ordonnancement : les frères ne doivent pas être double-réservés pour les services critiques.
5. Validez la posture sécurité : atténuations, ligne de commande du noyau, acceptation conformité.
6. Plan de rollback : paramètre BIOS ou noyau, et automatisation pour appliquer l’état désiré.

Checklist C: Si vous laissez le SMT activé, imposez l’hygiène des frères

1. Cartographiez les paires de frères une fois par plateforme et conservez-la dans l’inventaire métadonnées.
2. Épinglez les charges critiques sur des cœurs physiques, pas sur des IDs CPU arbitraires.
3. Séparez les CPU chargés en IRQ des cœurs latence.
4. Limitez les charges bruyantes par cgroups/quotas, et vérifiez que vous ne throttlez pas vos pods « importants ».
5. Testez sous contention, pas seulement sous charge moyenne.

FAQ

1) Le SMT d’AMD est-il essentiellement la même chose que l’Hyper-Threading d’Intel ?

Conceptuellement oui : deux threads matériels partagent les ressources d’exécution d’un cœur physique. Opérationnellement, vous devez quand même
traiter les frères comme une capacité partagée. Les différences apparaissent dans la topologie, le comportement cache/fabric, et les valeurs par défaut de la plateforme.

2) Dois-je désactiver le SMT sur AMD EPYC pour les bases de données ?

Si vous exécutez de l’OLTP sensible à la latence et que le p99 est critique, testez SMT désactivé ou une isolation stricte des frères. Si vous exécutez des
requêtes analytiques lourdes orientées débit, le SMT peut aider. Ne décidez pas d’après le bouche-à-oreille — décidez d’après le p99 et les compteurs.

3) Pourquoi l’utilisation CPU semble-t-elle plus faible avec le SMT activé ?

Parce que l’utilisation est signalée par CPU logique. Deux frères à 50 % peuvent encore signifier que le cœur physique est pleinement en contention.
Utilisez la file d’exécution, l’IPC et les métriques de latence pour interpréter la « marge ».

4) Puis-je garder le SMT activé tout en obtenant une latence prévisible ?

Parfois. La stratégie consiste en l’isolation : épinglez les charges critiques sur des cœurs physiques et gardez les voisins bruyants hors des threads frères.
Éloignez aussi les IRQ de ces cœurs. C’est plus difficile que « SMT désactivé », mais cela préserve le débit pour d’autres niveaux.

5) Quelle est la façon la plus rapide de voir les paires de frères SMT sur Linux ?

Lisez /sys/devices/system/cpu/cpu*/topology/thread_siblings_list. C’est la source faisant foi pour la façon dont le noyau voit les groupes de frères.

6) Le SMT augmente-t-il le risque de sécurité ?

Le SMT peut augmenter l’exposition à certaines attaques par canaux auxiliaires inter-threads parce que deux threads partagent les ressources du cœur.
Beaucoup d’organisations gèrent cela en désactivant le SMT pour des charges multi-tenant ou à haut risque, tout en le laissant activé pour des hôtes dédiés avec atténuations.

7) Dans Kubernetes, pourquoi les pods « Guaranteed » se contendent-ils encore ?

Parce que « Guaranteed » signifie généralement que vous obtenez des CPU logiques dédiés, pas forcément des cœurs physiques dédiés.
Si une autre charge atterrit sur le frère, vous partagez encore le cœur. Utilisez le CPU Manager statique et une allocation consciente de la topologie.

8) Comment choisir entre « SMT désactivé » et « épinglage/isolation » ?

Si vous avez la maturité opérationnelle pour appliquer l’épinglage et surveiller la dérive, l’isolation est souvent meilleure pour des flottes mixtes.
Si vous avez besoin d’une prévisibilité simple et robuste pour un niveau dédié, SMT désactivé est une politique propre.

9) Pourquoi l’activation du SMT a-t-elle augmenté les context switches ?

Plus de CPU logiques peuvent augmenter les opportunités d’ordonnancement et les motifs de migration, surtout si vous avez aussi augmenté le nombre de workers.
Souvent la correction consiste à réduire les threads, améliorer l’affinité, et éviter la sur-souscription.

Conclusion : que faire lundi matin

Le SMT d’AMD a cessé d’être une « fonctionnalité à la Intel » au moment où EPYC est devenu un choix de production sérieux. Traitez-le comme une politique plateforme, pas comme une anecdote BIOS. Le SMT peut vous apporter du débit, mais il vous facturera volontiers en latence extrême si vous laissez des threads lourds s’entasser sur des frères.

Prochaines étapes qui font vraiment bouger les choses :

1. Inventoriez votre flotte : état SMT, cœurs/sockets, disposition NUMA. Rendre « CPU physique vs logique » explicite dans les dashboards.
2. Choisissez un service critique pour la latence et réalisez une expérience contrôlée SMT activé vs SMT désactivé avec une charge identique.
3. Si le SMT reste activé, imposez l’hygiène des frères : épinglage, ensembles CPU et affinité IRQ qui respectent les cœurs physiques.
4. Rédigez la politique : quelles classes de nœuds sont SMT activé, quelles sont SMT désactivé, et quelles portes d’acceptation décident des changements.

Si vous ne retenez qu’une idée : le SMT ne vise pas à gagner des benchmarks. Il s’agit de choisir où vous voulez que la contention ait lieu — puis d’appliquer cette décision.