AMD SMT: коли «функція Intel» стала реальним конкурентом

Що насправді таке SMT (і чим воно не є)

SMT дозволяє одному фізичному ядру представляти декілька логічних CPU операційній системі. На більшості сучасних серверних AMD-модельних плат це 2 потоки на ядро (SMT2).
Планувальник бачить два «CPU». Ядро бачить один набір виконавчих ресурсів, якими діляться два архітектурні стани.

Останнє речення — операційна суть: два потоки ділять щось. Вони не магічно стають двома ядрами.
На практиці вони ділять ресурси фронтенду, виконавчі блоки, кеші різних рівнів і — критично — шляхи конкуренції, які ви помічаєте лише на p95/p99. SMT — це ставка на те, що коли один потік зупиняється (cache miss, branch mispredict, очікування пам’яті),
інший може використати інакше незайняті блоки.

SMT — це не «безкоштовні ядра»

ОС із задоволенням запланує два завантажені потоки на сусідів одного фізичного ядра, якщо ви їй цього дозволите.
Пропускна здатність може зрости, затримки — погіршитись, а графіки CPU будуть самозаспокійливо повідомляти «не насичено».
Так ви отримуєте CPU «лише» на 60% зайняті, поки ваші користувачі оновлюють сторінку, наче це 2009 рік.

SMT — це контракт планувальника, про який ви не знали

Увімкнення SMT змінює топологію, яку бачить ОС. Це змінює, як ви прив’язуєте vCPU, як розділяєте навантаження, як читаєте «використання CPU» і як інтерпретуєте perf-лічильники. Воно також може змінити профіль ризику для side‑channel атак і пов’язані міри пом’якшення.

Суха правда: якщо ви явно не вирішили, як використовувати SMT-сестринські потоки, Linux вирішить за вас, і Linux оптимізує під пропускну здатність і справедливість — іноді за рахунок ваших хвостових затримок.

Як AMD зробив SMT конкурентоспроможним: від «милого» до «серйозного»

Довгий час «SMT» у публічній уяві означало Hyper-Threading від Intel. AMD мав історії з багатопоточністю до Zen, але саме Zen (а особливо EPYC) зробили AMD SMT операційно релевантним у тих самих розмовах, що й Intel.

Важливий зсув був не в маркетингу. Це була архітектура, що зіткнулася з реальністю платформи: більша кількість ядер, краща продуктивність на ядро та серверна екосистема, яка раптом почала серйозно ставитись до AMD. Коли ви розгортаєте стоси з EPYC, ви перестаєте ставитися до SMT як до примітки. Ви починаєте ставити його як політику.

Чому з’явився «реальний конкурент»

• Кількість ядер поставила питання. На серверах з великою кількістю ядер ви можете обирати між «більше потоків зараз» і «більше ізоляції».
• Планувальники стали зрілішими. Усвідомлення топології в Linux покращилося; адміністратори навчилися враховувати відносини між сестринськими CPU.
• Хмарні сервіси зробили це проблемою для всіх. Багатоквартирна конкуренція й ефекти шумних сусідів перетворюють SMT на бізнес-рішення.
• Безпека заговорила голосно. SMT увійшло в моделі загроз; деякі організації відключили його за замовчуванням після великих розкриттів спекулятивного виконання.

Висновок: AMD SMT — це не підробка. Це значущий руків з відомими компромісами — але деталі топології EPYC (ера CCD/CCX, NUMA-розклад, поведінка кешу) значать, що правила із епохи Intel не можна копіювати без адаптації.

Факти й історія, які можна використати на дошці

Конкретні контекстні точки — корисні, щоб пояснити, чому ваш план «просто увімкнути SMT» потребує супроводу тест-планом.

1. Intel широко випустив Hyper-Threading на початку 2000-х. Це десятиліттями формувало індустріальну модель SMT.
2. Дизайн «module» епохи Bulldozer від AMD не був SMT. Він ділив деякі ресурси між двома цілими ядрами; це плутало покупців і бенчмарки.
3. Zen (2017) приніс мейнстримний AMD SMT у сервери. EPYC зробив SMT очікуваною опцією в центрах обробки даних на AMD.
4. Ранні покоління EPYC виявили складну топологію. Поведінка NUMA і домени кешу стали важливішими за «кількість потоків на ядро».
5. Linux-планувальники покращили пакування й розподіл. Топологічно‑усвідомлене планування зменшило деякі класичні патології HT/SMT, але не всі.
6. Розкриття спекулятивного виконання змінило налаштування за замовчуванням. Після 2018 року багато підприємств переглянули політику SMT через ризик витоку між потоками.
7. Деякі гіперскейлери обрали SMT‑on для пропускної здатності, SMT‑off для певних рівнів. Ера «один розмір підходить усім» закінчилася.
8. Приріст продуктивності від SMT специфічний для навантаження. Для багатьох серверних навантажень SMT дає помірний приріст; для інших — негатив при конкуренції ресурсів.

Якщо потрібна одна модель розуміння: SMT найкраще, коли один потік залишає «порожнини» в конвеєрі, які інший може заповнити.
SMT найгірше, коли обидва потоки хочуть одні й ті ж гарячі ресурси одночасно.

Реальність продуктивності: де SMT допомагає, шкодить і вводить в оману

Де SMT зазвичай допомагає

SMT зазвичай допомагає, коли у вас багато незалежної роботи, яка часто блокується: сервіси з великою кількістю запитів і очікуванням I/O,
змішані потоки інструкцій, гілки з великою кількістю умов, кеш‑промахи і достатня паралельність, щоб утримувати машину зайнятою.
Системи, орієнтовані на пропускну здатність (пакетна обробка, деякі веб-шари, фонові споживачі черг) часто бачать вигоду.

Де SMT часто шкодить

SMT може зашкодити, коли вам важлива стабільна затримка на запит, або коли навантаження вже високо оптимізоване і насичує виконавчі ресурси.
Сестринський потік стає не допомогою, а джерелом конкуренції.
Класичні жертви: низьколатентні системи на кшталт трейдингу (навіть якщо ви не торгуєте), завантажені OLTP бази, і шлях збереження даних, де важливі блокування й поведінка кешу.

Оман: «CPU utilization низький, отже CPU не вузьке місце»

З SMT ви можете мати ядро з двома сестрами, кожна по 50% «utilization», при цьому фізичне ядро ефективно насичене на критичному ресурсі.
Ви бачите простій, бо вимірювання робиться по логічних CPU, а не по фізичних ресурсах.

Якщо ваш p99 погіршився після вмикання SMT, не сперечайтесь із графіком. Сперечайтесь з планувальником і лічильниками.

Контенція ресурсів, на які варто звертати увагу

• Тиск на L1/L2 і конфлікти фронтенду інструкцій. Два гарячі потоки борються за одні й ті ж дрібні швидкі ресурси.
• Спільні виконавчі блоки. Якщо обидва потоки важкі по одному типу блоків, SMT стає самообтяженням.
• Кеш і пропускна здатність пам’яті. SMT може збільшити кількість одночасних запитів до пам’яті, що або допомагає, або насичує fabric.
• Блокування й спін-цикли. SMT може перетворити «трохи спінінгу» на «два потоки, що палять одне і те ж ядро».
• Навантаження ядра і переривання. Неправильне розміщення IRQ разом зі SMT може додати джиттеру вашим «виділеним» ядрам.

Цитата, яку варто повісити на стіну, бо вона застосовується до рішень про SMT так само, як і до інцидент-менеджменту:
Hope is not a strategy. —General James N. Mattis

Операційна версія: вимірюйте, змінюйте одну змінну й підозрюйте покращення, що показуються лише в середніх значеннях.

Жарт №1: SMT — як додати другого водія на вилочний навантажувач. Іноді ви перевозите більше піддонів; іноді ви просто голосніше сваритесь в одному проході.

Швидкий план діагностики (знайти вузьке місце швидко)

Коли сервіс уповільнюється і SMT може бути причетним, вам потрібен детермінований порядок триажу. Ось найшвидший шлях, який я знайшов,
щоб не витратити післяобідній час на суб’єктивні враження.

1) Підтвердьте топологію та стан SMT

• Скільки сокетів? Скільки ядер на сокет? Чи ввімкнено SMT?
• Ви в голові рахуєте «vCPU» чи «фізичні ядра»?

2) Визначте, чи ви прив’язані до пропускної здатності чи до латентності

• Якщо болить p95/p99: припускайте конкуренцію/джиттер, поки не доведено зворотнє.
• Якщо болять черги та загальна пропускна здатність: SMT може допомогти, але лише якщо ви не насичуєте пам’ять/блокування.

3) Перевірте чергу виконання та тиск на CPU (не лише CPU%)

• Run queue > число фізичних ядер: тиск планування реальний.
• Високий iowait не означає «диск повільний»; це може значити «потоки блокуються і CPU недоотримує роботу».

4) Шукайте контенцію між сестринськими потоками

• Чи два важкі потоки співплануються на сестринських CPU?
• Чи IRQ потрапляють на ті ж фізичні ядра, до яких ви прив’язали критичні за латентністю навантаження?

5) Використовуйте лічильники для підтвердження

• Контекстні переключення, міграції, частоти кеш‑промахів, stalled cycles.
• Порівняйте SMT‑on проти SMT‑off на тому самому класі хостів, якщо можете.

6) Рішення: зміна політики чи зміна прив’язки?

• Якщо вам потрібна передбачувана латентність: віддавайте перевагу SMT off або суворій ізоляції сестринських потоків.
• Якщо вам потрібна пропускна здатність і ви можете терпіти джиттер: віддавайте перевагу SMT on з розумним розміщенням.

Практичні задачі: команди, виводи, рішення (12+)

Це задачі, які ви виконуєте під час розслідування продуктивності або огляду готовності платформи. Кожна містить:
команду, правдоподібний фрагмент виводу, що це означає і яке рішення прийняти далі.

Задача 1: Перевірити, чи SMT увімкнено/вимкнено через інтерфейс ядра

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

Значення: Ядро дозволяє сестринським CPU бути онлайн.

Рішення: Якщо ви розслідуюєте хвостову латентність, майте це на увазі; можете протестувати варіант off або прив’язку сестринських потоків.

Задача 2: Перевірити, скільки потоків на ядро у вас фактично

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

Значення: 64 фізичних ядер, 128 логічних CPU. SMT присутнє.

Рішення: Будь‑який «рахунок CPU», який ви використовуєте в плануванні місткості, має бути явним: фізичні vs логічні.

Задача 3: Змапити пари сестринських CPU (хто з ким ділить ядро)

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

Значення: CPU0 ділить фізичне ядро з CPU64, і т.д.

Рішення: При прив’язуванні враховуйте сестринські пари як один спільний ресурс. Розміщуйте конкуруючі важкі потоки на різних фізичних ядрах, а не лише на різних логічних CPU.

Задача 4: Підтвердити NUMA-розклад (рішення щодо SMT — це топологічні рішення)

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

Значення: Два NUMA‑вузли; у цьому прикладі межі вузлів вирівняні з діапазонами CPU.

Рішення: Якщо затратно‑чутливий додаток ненавмисно охоплює NUMA‑вузли, виправте розміщення NUMA перед тим, як звинувачувати SMT.

Задача 5: Швидко спостерігати чергу виконання та тиск на CPU

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

Значення: r (run queue) високий відносно числа фізичних ядер на NUMA‑вузол; контекстні переключення підвищені.

Рішення: Розслідуйте конкуренцію планування і прив’язку. Високий cs разом зі SMT може посилити джиттер.

Задача 6: Перевірити використання по CPU, щоб знайти перевантажені сестри

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

Значення: Обидві сестри одного ядра гарячі. Це фізичне ядро, ймовірно, має високий рівень конкуренції.

Рішення: Розпреділяйте важкі воркери по фізичних ядрах у першу чергу; не пакуйте їх на сестринські потоки.

Задача 7: Визначити міграційний шум CPU (шкідливий для локальності кешу і латентності)

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

Значення: Багато добровільних та недобровільних переключень контексту; потенційна конкуренція або препемпція.

Рішення: Якщо це критично за латентністю, розгляньте CPU affinity, ізоляцію cgroup і уникнення спільного використання сестринських потоків.

Задача 8: Перевірити пропускну здатність CFS (поширена пастка «SMT зробило гірше»)

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

Значення: Навантаження обмежується квотою CFS. SMT може приховати або посилити це, змінюючи відчуття ємності.

Рішення: Виправте квоти/ресурси спочатку. Політика SMT не повинна компенсувати некоректні ліміти cgroup.

Задача 9: Перевірити розподіл IRQ (переривання крадуть ваші «виділені» ядра)

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

Значення: CPU0 обробляє більшість NVMe-переривань. Якщо CPU0 — сестра критичного воркера за латентністю, готуйтеся до джиттера.

Рішення: Перерозподіліть IRQ affinity подалі від критичних ядер; не дозволяйте сестрам SMT ділити CPU з інтенсивними IRQ.

Задача 10: Перевірити kernel mitigations, що взаємодіють зі SMT/безпекою

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

Значення: Міри пом’якшення ввімкнено автоматично; SMT явно не вимкнено через nosmt.

Рішення: Узгодьте з політикою безпеки. Деякі організації вимагають SMT вимкненим; інші приймають міри пом’якшення і ізоляцію.

Задача 11: Порівняти пропускну здатність і stalls за допомогою perf

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

Значення: IPC, cache misses і context switches дають перевірку на адекватність. Якщо IPC падає і кеш‑промахи ростуть після ввімкнення SMT, ви платите податок конкуренції.

Рішення: Якщо p99 погано і IPC/кеші виглядають гірше з SMT on, протестуйте SMT off або забезпечте ізоляцію сестринських потоків.

Задача 12: Перевірити, чи ядро відключило деякі сестринські CPU (часткове вимкнення SMT)

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

Значення: Сестри онлайн. Якщо бачите 0, SMT може бути фактично знижено шляхом офлайнінгу CPU.

Рішення: Стандартизувати: керуйте SMT через BIOS/kernel опції або через контрольовані CPU set-и — не залишайте напівсконфігурований стан по флоту.

Задача 13: Прив’язати процес подалі від сестринських CPU (швидкий експеримент)

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

Значення: Процес обмежено підмножиною CPU (ід ideally вирівняно по фізичних ядрах).

Рішення: Якщо латентність покращилася, це не обов’язково означає, що потрібно вимикати SMT — вам потрібне краще розміщення.

Задача 14: Підтвердити, що ваш CPU set випадково не включає сестринські пари

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

Значення: Ви створили CPU shield (через cpuset) для ізоляції. Але вам все одно потрібно переконатися, що ці CPU чисті по фізичних ядрах.

Рішення: Використовуйте мапу thread_siblings_list, щоб будувати cpuset-и, які не ставлять два важкі завдання на одне ядро.

Жарт №2: Вимикати SMT, щоб виправити латентність без вимірювання — це як перезавантажувати маршрутизатор, щоб полагодити DNS: іноді допомагає, і ви нічого не дізнаєтесь.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через неправильне припущення

Середнього розміру SaaS компанія мігрувала основний API‑рівень з старих Intel-серверів на блискучі AMD EPYC хости. Мета була проста:
знизити вартість за запит. Вони зберегли ті самі Kubernetes CPU requests/limits і трактували «vCPU» як «ядро», бо старий світ в основному так працював.

Розгортання в staging виглядало добре. У продакшні p99 латентність подвоїлася при піковому навантаженні. Графіки CPU були нудні: 55–65%,
нічого страшного. Команда on-call ганялася за запитами до БД, потім за мережею, потім за налаштуванням GC. Сервіс «не був CPU-зв’язаний»,
тому ніхто не чіпав політику CPU.

Помилка: вони припустили, що два логічні CPU еквівалентні двом фізичним ядрам для їхнього навантаження. Насправді їх обробники запитів вже були CPU‑гарячими й гілкуючими,
і вони розмістили кілька важких pod-ів так, що сестри постійно конкурували. Linux був «справедливим», а навантаження — покаране.

Виправлення не було драматичним. Вони змепили сестринські пари, відкоригували CPU Manager policy для латентного шару і забезпечили,
щоб «guaranteed» pod-и отримували повні ядра (і не ділилися сестрами з іншими важкими pod-ами). Вони також перестали трактувати «65% CPU» як «запас».
Після змін p99 повернувся близько до бази з трохи нижчою пропускною здатністю, ніж при упакованій SMT-конфігурації — але стало передбачувано, а саме за це платять клієнти.

Урок: інцидент не був «AMD SMT поганий». Інцидент був «ми не визначили, що таке CPU у нашій платформі».
Коли ви помиляєтесь у одиницях, будь‑який дашборд чемно брешіть.

Міні-історія 2: Оптимізація, що відскочила назад

Команда дата‑платформи запускала змішане навантаження на великих EPYC: streaming ingest service, стиснення в пакетах і storage gateway.
Хтось помітив, що пакетна задача працює лише вночі. Вирішили «позичити» CPU вдень, увімкнувши SMT і збільшивши кількість воркерів для ingest сервісу. Більше потоків — більше пропускної здатності, правда?

Перший день виглядав чудово — середня пропускна здатність зросла і CPU utilization піднявся. Другого дня customer‑фейсні дашборди почали періодично тайм-аутитись.
Не постійно. Але достатньо, щоб злити нерви. Storage gateway мав спорадичні спайки латентності, які не відображалися в середніх, але ламали все, що має таймаути.

Корінь: додаткові потоки ingest потрапляли на SMT‑сестри критичних воркерів gateway. Gateway мав періодичні CPU‑інтенсивні сплески (контрольні суми, шифрування, метадані).
Під конкуренцією SMT ці сплески подовжились, і черги розшарувалися. Система не впала гучно; вона впала бюрократично — повільно, неперервно і неможливо покарати один метрик.

Ролбек відновив стабільність. Потім зміни ввели правильно: ізолювали gateway на повні фізичні ядра, перемістили ingest на інші ядра і обмежили воркерів ingest
на основі пропускної здатності пам’яті і конкуренції за блокування, а не «доступних потоків».

Урок: перемоги за пропускною здатністю, які крадуть хвостову латентність, — не перемоги. SMT — це спільний апаратний ресурс; якщо ви не встановите межі, він встановить їх за вас, і зробить це погано.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінансова команда мала два класи вузлів: загального призначення і чутливі до латентності. Їх політика була неефектною, але правильною: SMT увімкнено для загальних вузлів, SMT вимкнено (або ізольовано сестри) для латентних вузлів. Кожна зміна вимагала A/B тесту з відтворенням навантаження, збором perf‑лічильників і p99‑воріт прийнятності.

Під час великого оновлення ОС один зміна в kernel‑плануванні змусила деякі навантаження більше мігрувати між CPU. Різниця була тонкою; більшість дашбордів цього не помітила. Але тести на латентність помітили регресію в p99 у класі латентності.

Вони не сперечались про теорію. Порівняли perf‑статистики, швидкість переключень контексту і кількість міграцій між старим і новим kernel, потім довше прив’язали критичний сервіс і відкоригували IRQ affinity.
Оновлення пройшло без видимого клієнтам інциденту.

Урок: «нудні ворота» і відтворювані тести перемагають кмітливість. SMT взаємодіє з планувальниками, kernel і мікрокодом. Якщо у вас немає хардвера тестування — у вас не контроль, а надія.

Типові помилки: симптом → корінь → виправлення

1) Симптом: p99‑спайки після ввімкнення SMT, але CPU% виглядає нормально

Корінь: Два гарячі потоки співплановано на сестринських CPU; логічна зайнятість приховує фізичну конкуренцію.

Виправлення: Прив’язуйте критичні за латентністю воркери до повних фізичних ядер або ізолюйте сестринські потоки; перевіряйте мапу сестринства і perf‑лічильники.

2) Симптом: «Більше vCPU» у ВМ не підвищило пропускну здатність

Корінь: vCPU потрапили на сестри або на перевантажені ядра; хост обмежений конкуренцією (кеш/пам’ять/блокування).

Виправлення: Використовуйте pinning з урахуванням сестер; зменшіть число vCPU, щоб відповідати фізичним ядрам для критичних ВМ; вимірюйте run queue і IPC.

3) Симптом: Kubernetes Guaranteed pod-и все одно показують джиттер

Корінь: Виділені CPU не були справді виділені — сестри ділилися з іншими навантаженнями, або IRQ потрапляли на ті ж ядра.

Виправлення: Використовуйте static CPU Manager з алокацією цілих ядер і переконайтесь, що IRQ affinity уникає цих ядер.

4) Симптом: Вимкнення SMT покращило латентність, але сильно впало пропускання

Корінь: Ви використовували SMT як загальну політику замість розміщення по рівнях; деякі навантаження виграють від SMT, деякі — програють.

Виправлення: Розділіть node pool-и: SMT‑on для шарів пропускної здатності, SMT‑off або ізольовані сестри для латентних шарів. Не змішуйте без явного pinning.

5) Симптом: Високі переключення контексту й міграції, нестабільна продуктивність

Корінь: Хаос планувальника підсилений надто великою кількістю runnable потоків і відсутністю affinity; SMT збільшує площу планування.

Виправлення: Зменшіть кількість воркерів; прив’язуйте або обмежуйте CPU set-и; перевірте throttling cgroup; налаштуйте розміщення IRQ.

6) Симптом: Команда безпеки вимагає вимкнути SMT «повсюди»

Корінь: Політика, що реагує на ризик side‑channel між потоками; інженери не запропонували альтернативу з рівнями ризику.

Виправлення: Визначте класи навантажень і межі ізоляції; для багатоквартирних або високоризикових навантажень SMT off може бути правильним. Для виділених хостів SMT on може бути прийнятним.

7) Симптом: Ноди зберігання показують періодичні «обриви» латентності

Корінь: Переривальні шторми або kernel‑потоки конкурують з app‑потоками на тих же фізичних ядрах; сестринські потоки страждають.

Виправлення: Перегляньте /proc/interrupts, перерозподіліть IRQ, зарезервуйте ядра для IO-шляхів і уникайте прив’язки app‑воркерів до CPU з інтенсивними IRQ.

Чеклісти / покроковий план

Чекліст A: Вирішити, чи варто вмикати SMT для класу вузлів

1. Класифікуйте навантаження. Шар пропускної здатності чи шар латентності? Якщо не можете відповісти — за замовчуванням вважайте латентним.
2. Виміряйте базу. Зніміть p50/p95/p99, error rates, run queue, IPC, cache misses.
3. Змініть одну річ. Перемкніть SMT або забезпечте ізоляцію сестер — не робіть обидва одразу.
4. Перезапустіть те саме навантаження. Відтворіть production‑трафік або використайте стабільний синтетичний тест.
5. Проходьте по p99 і сигналам насичення. Середні не мають право приймати політику платформи.
6. Документуйте, що означає «CPU». У квотах, моделях місткості і дашбордах: логічний vs фізичний.

Чекліст B: Безпечне впровадження зміни політики SMT

1. Виберіть один клас хостів і один регіон/кластер.
2. Увімкніть деталізовану метрику хоста: по‑CPU, run queue, міграції, розподіл IRQ.
3. Запустіть канарею з невеликим відсотком і порівнюйте когорти.
4. Перевірте розміщення планування: сестри не повинні бути подвійно записані для критичних сервісів.
5. Підтвердіть безпекову позицію: mitigations, cmdline ядра, підпис згідно комплаєнсу.
6. План відкату: налаштування BIOS або параметри kernel і автоматизація для примусового підтримання бажаного стану.

Чекліст C: Якщо залишаєте SMT ввімкненим — забезпечте гігієну сестер

1. Замепте пари сестер один раз для платформи і зберігайте в інвентарі метаданих.
2. Прив’язуйте критичні навантаження до фізичних ядер, а не до довільних ID CPU.
3. Відокремлюйте CPU з інтенсивним IRQ від латентних ядер.
4. Обмежуйте шумні навантаження через cgroups/quotas і перевіряйте, що ви не тротлите важливі pods.
5. Тестуйте під конкуренцією, а не лише під середнім навантаженням.

ЧаПи

1) Чи AMD SMT фактично те саме, що Intel Hyper-Threading?

Концептуально — так: два апаратні потоки ділять виконавчі ресурси одного фізичного ядра. Операційно — ви все одно маєте трактувати сестринські потоки як спільну ємність.
Відмінності проявляються в топології, поведінці кешів/fabric і платфомних налаштуваннях.

2) Чи варто вимикати SMT на AMD EPYC для баз даних?

Якщо ви працюєте з латентним OLTP і p99 важливий — тестуйте SMT off або сувору ізоляцію сестер. Якщо у вас аналітичні запити, орієнтовані на пропускну здатність, SMT може допомогти.
Не вирішуйте за чутками — вирішуйте за p99 і лічильниками.

3) Чому CPU utilization виглядає нижчим при SMT on?

Тому що використання відображається по логічних CPU. Дві сестри по 50% можуть означати, що фізичне ядро повністю сковано на критичному ресурсі.
Використовуйте run queue, IPC і метрики латентності, щоб інтерпретувати «запас».

4) Чи можна залишити SMT ввімкненим і отримати передбачувану латентність?

Іноді. Підхід — ізоляція: прив’язуйте критичні навантаження до фізичних ядер і тримайте шумних сусідів подалі від сестринських потоків.
Також тримайте IRQ подалі від цих ядер. Це складніше, ніж «SMT off», але зберігає пропускну здатність для інших шарів.

5) Який найшвидший спосіб побачити пари сестринських CPU в Linux?

Читайте /sys/devices/system/cpu/cpu*/topology/thread_siblings_list. Це авторитетне джерело того, як ядро бачить групи сестер.

6) Чи підвищує SMT ризик для безпеки?

SMT може збільшити експозицію до деяких cross‑thread side‑channel атак, оскільки два потоки ділять ресурси ядра. Багато організацій вирішують відключати SMT для багатоквартирних або високоризикових робіт, водночас зберігаючи його для виділених хостів з мірами пом’якшення.

7) Чому в Kubernetes «Guaranteed» pod-и все одно конкурують?

Бо «Guaranteed» зазвичай означає виділені логічні CPU, а не обов’язково виділені фізичні ядра.
Якщо інше навантаження сяде на сестру, ви все одно ділите ядро. Використовуйте static CPU Manager і топологічно‑усвідомлене розміщення.

8) Як вирішити між «SMT off» і «pinning/isolating»?

Якщо у вас є операційна зрілість для підтримки pinning і моніторингу дрейфу — ізоляція часто краща для змішаних флотів.
Якщо вам потрібна проста, надійна передбачуваність для виділеного шару — SMT off це чиста політика.

9) Чому ввімкнення SMT збільшило кількість переключень контексту?

Більше логічних CPU може збільшити можливості планування і патерни міграції, особливо якщо ви також збільшили кількість воркерів.
Часто виправлення — зменшити потоки, краще affinity і уникати over‑subscription.

Висновок: що робити в понеділок вранці

AMD SMT перестало бути «функцією схожою на Intel» у той момент, коли EPYC став серйозним продакшн‑за замовчуванням. Ставтеся до нього як до політики платформи, а не як до біосу‑тривіа.
SMT може купити вам пропускну здатність, але охоче візьме платню у вигляді хвостової латентності, як тільки важкі потоки наслояться на сестри.

Наступні кроки, які дійсно впливають:

1. Зробіть інвентар—стан SMT, ядра/сокети, NUMA‑розклад. Зробіть «фізичний vs логічний CPU» явним у дашбордах.
2. Виберіть один критичний сервіс за латентністю і проведіть контрольований експеримент SMT‑on vs SMT‑off з ідентичним навантаженням.
3. Якщо залишаєте SMT on — забезпечте гігієну сестер: pinning, CPU set-и й IRQ affinity, що поважають фізичні ядра.
4. Запишіть політику: які класи вузлів SMT‑on, які SMT‑off і які ворота прийнятності вирішують зміни.

Якщо ви візьмете тільки одну ідею: SMT — це не шлях до перемоги в бенчмарках. Це про вибір місця для конкуренції ресурсів — а потім примусове дотримання цього вибору.