P-ядра та E-ядра: гібридні CPU без маркетингу

Ментальна модель, що витримує контакт із продакшеном

P-ядра і E-ядра — це не просто «швидкі проти повільних» у простому лінійному сенсі. Думайте про них як про два класи обчислювальної потужності з різною
однонитковою продуктивністю, енергетично-тепловою поведінкою і іноді мікроархітектурними особливостями.
Планувальник ОС намагається розмістити потоки на «правильному» типі ядра. Інколи йому вдається. Інколи він впевнено помиляється.

Ось модель для продакшену:

• P-ядра: вища пропускна здатність на потік, кращі для задач чутливих до латентності та гіллястого коду,
  зазвичай вищі частоти й більше ресурсів out-of-order. Часто саме на них ви отримуєте найкращий турбобуст при легкому навантаженні.
• E-ядра: більше потоків на ватт і на мм², зазвичай нижчі частоти, відмінні для фонової пропускної здатності, паралельної роботи та задач «не будіть мене через це».
  Вони не марні — просто не там, де ви хочете, щоб жила хвостова латентність.
• Спільні обмеження залишаються: кеші, пропускна здатність пам’яті, кільце/mesh інтерконект, ліміти потужності пакету та теплове дроселювання.
  Гібридність не усуває вузькі місця; вона додає нове: вибір класу ядра.

Ключовий операційний інсайт: ви більше не керуєте просто «використанням CPU». Ви керуєте тим, якого саме типу CPU ви використовуєте.
Хост може бути «лише на 35% завантажений» й одночасно не мати вільних P-ядер, бо решта потужності — на E-ядрах.

Сухий факт: гібридні CPU роблять погані дашборди ще кращими на вигляд. Єдина графіка «CPU %» із задоволенням скаже, що все в порядку,
поки ваші треди запитів стоять у черзі за купою лог-шиперів на E-ядрах.

Що змінюється, коли ядра не рівні

1) Планування ємності перестає бути скалярним

При однорідних ядрах «8 ядер» приблизно означає 8 копій одного й того ж виконувального двигуна. У гібриді «16 ядер» може означати
«8 швидших, 8 повільніших». Точне співвідношення й розрив залежать від покоління, частот, теплових умов та поведінки прошивки.
Тому ваша стара емпірична формула — запитів на ядро, збірок на ядро, потоків GC на ядро — стає неповною.

2) Рішення планувальника стають рішеннями продуктивності

На однорідних CPU планування здебільшого впливає на справедливість та локальність кешу. На гібридних CPU планувальник — ще й система рівневого розподілу продуктивності.
Помістіть нитку, критичну для латентності, на E-ядро — і ви не «втратили 10%». Ви змінили її весь розподіл часу обслуговування.
Саме так отримують добре p95 і погане p99.

3) Прив’язка й ізоляція стають ціннішими — і небезпечнішими

Прив’язка (pinning) може врятувати. Вона також може назавжди зафіксувати вас на невірних ядрах. Погана версія — «ми прив’язали до CPU 0-7 у 2022 і ніколи не переглянули».
На гібридній машині нумерація логічних CPU може чергувати типи ядер залежно від BIOS/прошивки/ОС.

4) Турбо, терміка й ліміти потужності важать більше, ніж ви хочете

Гібридні дизайни часто налаштовані на сплески: великі піки на P-ядрах, фонові задачі на E-ядрах і динамічний бюджет потужності.
У серверах стійке навантаження — це статус-кво, а не сюрприз. При тривалому навантаженні «швидкі ядра» можуть не залишатися такими швидкими,
а «ефективні ядра» можуть стати вашою базовою продуктивністю.

5) Вузьке місце може бути в самій міграції

Якщо треди перескакують між класами ядер, ви платите за холодні кеші, різні стани частоти й облік планувальника.
Міграції також змінюють лічильники продуктивності й плутають наївний профайлінг. Ви думаєте, що вимірюєте додаток. Ви вимірюєте настрій планувальника.

Жарт №1: гібридні CPU — як open-space офіси: комусь здається, що це ефективно, а хтось завжди у навушниках з шумоподавленням.

Факти та історичний контекст (коротко і по суті)

1. Big.LITTLE виник задовго до сучасних ПК. Концепція ARM big.LITTLE з’явилася на початку 2010-х для поєднання високопродуктивних і енергоефективних ядер у мобільних SoC,
   бо телефони живуть і вмирають через батарею та теплові умови.
2. Гетерогенне планування старше за гібридні ядра. Дата-центри давно стикалися з тим, що «не всі CPU рівні» через NUMA, різні turbo-біни та змішані stepping’и, але гібрид робить цю різницю явною й по ядру.
3. Мейнстрімний гібрид Intel з’явився з Alder Lake. Це покоління привнесло P- і E-ядра в масові десктопи, змусивши загальні планувальники ОС серйозно до цього поставитися.
4. Windows рано отримала історію апаратних підказок. Intel Thread Director дає підказки про «клас» нитки й її поведінку, які Windows активно використовує для розміщення.
5. Linux обрав більш загальний шлях. Замість покладання тільки на інтерфейс одного вендора, Linux побудував планування, що враховує ємність і типи ядер, працюючи на різних гетерогенних дизайнах, але якість залежить від версії ядра й платформи.
6. SMT/Hyper-Threading взаємодіє з гібридом неочевидно. Багато гібридних дизайнів мають SMT на P-ядрах, але не на E-ядрах.
   Тому «32 потоки» можуть означати «16 фізичних ядер, але тільки половина має SMT».
7. Нумерація CPU — не контракт. Ідентифікатори логічних CPU можуть відображатися на типи ядер по-різному в залежності від BIOS, мікрокоду і ядра.
   Скрипти, які припускають «CPU0..CPU7 — швидкі», — це спосіб створити інцидент.
8. Ліміти потужності можуть перетворити гібридний CPU на інший CPU. Під PL1/PL2 стійка продуктивність при всіх ядрах може вирівнятися,
   звужуючи розрив між P і E для задач пропускної здатності, але зберігаючи різницю в латентності.
9. Сімейства інстансів у хмарі вже «тихо» робили гетерогенність. Бурхливі інстанси, shared-core VM та поведінка шумних сусідів навчила багато команд шукати артефакти планувальника; гібрид робить ці артефакти можливими навіть на bare metal.

Реальність планувальника: Linux, Windows і всяка посередність

Linux: ємність, асиметрія й «податок» версії ядра

Сучасні планувальники Linux можуть розуміти, що деякі CPU мають більше «ємності», ніж інші. На практиці вас цікавить:
версія ядра, мікрокод/прошивка і чи чітко платформа показує топологію.

Ви намагаєтесь відповісти на два операційні питання:

• Чи віддає планувальник перевагу розміщенню задач з високим використанням на ядрах з більшою ємністю?
• Чи не залишається критично чутливих до латентності задач на E-ядрах під навантаженням?

Відповідь часто «переважно, якщо тільки ви не запускаєте контейнери, не прив’язуєте CPU, не маєте старого ядра або у вас є навантаження, яке евристики неправильно класифікують».
Це не скарга; це реальність. Планування — застосована статистика з гострими краями.

Windows: сильна поведінка за замовчуванням, але не магія

Windows на підтримуваних Intel гібридних системах використовує підказки Intel Thread Director для класифікації ниток і відповідного розміщення.
Це допомагає в інтерактивних і змішаних десктопних навантаженнях. У серверних навантаженнях все одно треба валідувати.
Фонові задачі можуть стати переднього плану у найгірший момент. Ваш «низькоприорітетний» пакет може тримати замок.

Віртуалізація й контейнери: ви можете приховати типи ядер, але не фізику

Гіпервізори можуть представляти vCPU, не показуючи гостю «це P-ядро», залежно від налаштування.
Це може спростити сумісність, але також перешкоджати гостьовій ОС робити хороші рішення розміщення.

Контейнери в певному сенсі гірші: вони заохочують прив’язку CPU («просто дайте цьому поду 4 CPU»), водночас приховуючи топологію.
Якщо ваша прив’язка потрапляє на E-ядра — вітаю з «оптимізацією витрат», що виглядає як регресія.

Перефразовуючи ідею Gene Kim: робота над надійністю — це робити режими відмов очевидними й відновлюваними, а не вдавати, що вони не відбудуться.
Гібридне планування додає нові режими відмов; ваше завдання — зробити їх видимими.

Які навантаження потребують P-ядер, а які терплять E-ядра

Шляхи обробки запитів, чутливі до латентності: P-ядра за замовчуванням

Якщо нитка торкається вашого SLO — ставте її в першу чергу. Обробники веб-запитів, RPC-воркери, передові треди баз даних,
IO-стрижі брокерів повідомлень, демони збереження даних, чутливі до хвостової латентності — вони мають бути на P-ядрах, коли це можливо.

Чому? Бо однониткова продуктивність і стабільні частоти важать більше за агрегований пропуск, коли ви гонитеся за p99.
E-ядра можуть бути прийнятні для середньої латентності, але дивувати вас у хвостах, коли система завантажена й зростає конкуренція.

Фонова пропускна здатність: E-ядра чудові — доки не стають ні

Стиснення логів, збір метрик, пакетні ETL, відео транскодинг, збірки CI, індексація, антивірусні сканування (так, ще бувають),
та «запустимо щотижневий звіт опівдні» — усе це добре працює на E-ядрах.

Пастка: фонова робота часто ділиться ресурсами й блокуваннями з фронтальними задачами. Так «E-ядро-робота» перетворюється на «P-ядро-інцидент».
Якщо ваш фоновий процес тримає mutex, потрібний запитам, то не має значення, що він «низького пріоритету». Тепер це підсилювач латентності.

Сховища й мережа: вужче місце переміщується

Сховища можуть бути CPU-bound (стиснення, контрольні суми, шифрування, erasure coding), memory-bound (копіювання, page cache) або IO-bound.
Гібрид впливає на CPU-bound частини та на частини «прокинься, оброби переривання, зроби дрібну роботу».

Для високих пакетних швидкостей, дрібних блоків зберігання або великої кількості TLS часто хочеться P-ядра для «гарячої» шляху і E-ядра для всього іншого.
Реальна вигода — ізоляція: тримайте шумну роботу подалі від детермінованого шляху.

Сміттєзбірники та runtime: не дозволяйте їм вибирати за вас

JVM, Go, .NET, Node — рантайми створюють допоміжні потоки, треди GC, JIT-потоки. Якщо вони потраплять на E-ядра, а потоки застосунку — на P-ядра,
ви все одно можете отримати паузи через повільність допоміжних потоків. Якщо потоки застосунку опиняться на E-ядрах — отримаєте повільний час обслуговування.
В обох випадках потрібно спостерігати розміщення ниток і налаштовувати.

Жарт №2: «Більше ядер» — чудовий план, поки ви не зрозумієте, що половина з них — стажери: ентузіастичні, корисні, але не ті, кому ви хочете довірити операцію.

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

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

Завдання 1: Швидко ідентифікувати CPU і гібридну топологію

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|NUMA|Vendor'
Vendor ID:                           GenuineIntel
Model name:                          13th Gen Intel(R) Core(TM) i9-13900K
CPU(s):                              32
Thread(s) per core:                  2
Core(s) per socket:                  24
Socket(s):                           1
NUMA node(s):                        1

Значення: 24 фізичних ядер, 32 логічних CPU. Такий патерн часто свідчить про SMT на деяких ядрах (зазвичай P-ядра) і відсутність на інших (часто E-ядра).

Рішення: Не припускайте, що «32 потоки» рівноцінні. Спочатку виявте типи ядер перед прив’язкою.

Завдання 2: Відобразити логічні CPU за типом ядра (P vs E) через sysfs

cr0x@server:~$ for c in /sys/devices/system/cpu/cpu[0-9]*; do \
  n=${c##*cpu}; \
  cap=$(cat $c/cpu_capacity 2>/dev/null); \
  echo "cpu$n capacity=$cap"; \
done | head
cpu0 capacity=1024
cpu1 capacity=1024
cpu2 capacity=1024
cpu3 capacity=1024
cpu4 capacity=1024
cpu5 capacity=1024
cpu6 capacity=1024
cpu7 capacity=1024
cpu8 capacity=768
cpu9 capacity=768

Значення: Ємність відрізняється за CPU. Вища ємність зазвичай відповідає P-ядрам; нижча — E-ядрам. (Точні значення залежать від платформи.)

Рішення: Побудуйте набір CPU: P-ядра (capacity=1024) для чутливих до латентності навантажень; E-ядра для пакетних/фонових задач.

Завдання 3: Підтвердити відмінності в максимальної частоті по ядрам

cr0x@server:~$ sudo apt-get -y install linux-tools-common linux-tools-generic >/dev/null
cr0x@server:~$ sudo cpupower frequency-info -p | head -n 12
analyzing CPU 0:
  current policy: frequency should be within 800 MHz and 5500 MHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
analyzing CPU 8:
  current policy: frequency should be within 800 MHz and 4200 MHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.

Значення: CPU 0 має вищу межу, ніж CPU 8. Це узгоджується з поведінкою P vs E.

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

Завдання 4: Подивитися, як ядро маркує гібридні/асиметричні CPU

cr0x@server:~$ dmesg | egrep -i 'hybrid|asym|capacity|intel_pstate|sched' | head
[    0.412345] x86/cpu: Hybrid CPU detected.
[    0.512998] sched: CPU capacity scaling enabled
[    1.103221] intel_pstate: Intel P-state driver initializing

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

Рішення: Якщо на відомому гібридному обладнанні ви цього не бачите — підозрівайте проблему з ядром/BIOS/мікрокодом; сплануйте оновлення перед тим, як звинувачувати додаток.

Завдання 5: Перевірити поточний governor і вирішити, чи підходить він

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

Значення: Governor — schedutil (поширений за замовчуванням). Він реагує на сигнали використання від планувальника.

Рішення: Для вузлів, чутливих до латентності, розгляньте performance (або налаштовані профілі), якщо прискорення частоти викликає стрибки — після вимірювання енергії/терміки.

Завдання 6: Виміряти тиск черги виконання (CPU-starved?)

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
 3  0      0 8123456 123456 3456789  0    0     0     2  910 1820 18  6 75  0  0
 9  0      0 8123000 123456 3456800  0    0     0     0 1400 9000 42 12 46  0  0
 8  0      0 8122900 123456 3456900  0    0     0     0 1300 8700 44 10 46  0  0
 2  0      0 8122800 123456 3457000  0    0     0     0  980 2100 20  6 74  0  0

Значення: Стовпець r сплескує (черга виконання). Це — конкуренція за CPU. Це не каже, чи конкуренція на P-ядрах чи на E-ядрах.

Рішення: Якщо черга виконання висока під час стрибків латентності, перевірте, чи P-ядра не завантажені, а E-ядра — простоюють.

Завдання 7: Спостерігати використання по ядрах, щоб виявити насичення P-ядр

cr0x@server:~$ mpstat -P ALL 1 2 | egrep 'Average|^[0-9]' | head -n 20
00:00:01 AM  CPU   %usr %nice  %sys %iowait %irq %soft  %steal %guest %gnice %idle
00:00:01 AM    0  72.00  0.00  18.00    0.00 0.00  0.00    0.00   0.00   0.00 10.00
00:00:01 AM    1  70.00  0.00  20.00    0.00 0.00  0.00    0.00   0.00   0.00 10.00
00:00:01 AM    8  18.00  0.00   6.00    0.00 0.00  0.00    0.00   0.00   0.00 76.00
00:00:01 AM    9  20.00  0.00   5.00    0.00 0.00  0.00    0.00   0.00   0.00 75.00

Значення: CPU 0–1 завантажені; CPU 8–9 майже простоюють. Якщо 0–7 — P-ядра, а 8+ — E-ядра, ймовірно, ви наситили P-ядра.

Рішення: Зменшіть конкуренцію на P-ядрах: прив’яжіть «гарячі» треди до P-ядр, перемістіть фонову роботу на E-ядра або зменшіть конкурентність у латентному шляху.

Завдання 8: Перевірити, де процесу дозволено виконуватись (cpuset/affinity)

cr0x@server:~$ pidof nginx
2143
cr0x@server:~$ taskset -pc 2143
pid 2143's current affinity list: 0-31

Значення: Nginx може виконуватись будь-де. Це нормально, якщо планувальник розумний; ризиковано, якщо фонові задачі змагаються на P-ядрах.

Рішення: Якщо ви боретесь з хвостовою латентністю, розгляньте прив’язку nginx (або ваших воркерів) лише до P-ядр.

Завдання 9: Прив’язати сервіс, чутливий до латентності, до P-ядр (приклад)

cr0x@server:~$ sudo systemctl show -p MainPID myapi.service
MainPID=8812
cr0x@server:~$ sudo taskset -pc 0-7 8812
pid 8812's current affinity list: 0-31
pid 8812's new affinity list: 0-7

Значення: Головний процес обмежено CPU 0–7 (припускаючи, що це P-ядра за вашою мапою ємності).

Рішення: Перевірте покращення в p99 і впевніться, що ви не позбавили сервіс ресурсів, давши йому надто мало CPU.

Завдання 10: Перемістити фонова роботу на E-ядра через systemd CPUAffinity

cr0x@server:~$ sudo systemctl edit logshipper.service
cr0x@server:~$ sudo cat /etc/systemd/system/logshipper.service.d/override.conf
[Service]
CPUAffinity=8-31
Nice=10
cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart logshipper.service
cr0x@server:~$ sudo systemctl show -p CPUAffinity logshipper.service
CPUAffinity=8-31

Значення: Log shipper обмежено CPU 8–31 (ймовірно E-ядра + можливо SMT-сателіти залежно від топології).

Рішення: Це одне з найчистіших продакшенових рішень: захистіть гарячий шлях, ізолювавши галасливих сусідів.

Завдання 11: Перевірити розміщення потоків і міграції

cr0x@server:~$ pidof myapi
8812
cr0x@server:~$ ps -L -p 8812 -o pid,tid,psr,comm | head
  PID   TID PSR COMMAND
 8812  8812   2 myapi
 8812  8820   4 myapi
 8812  8821   6 myapi
 8812  8822   1 myapi

Значення: PSR — CPU, на якому тред останнім разом виконувався. Якщо ви бачите, що треди стрибають між діапазонами P і E, ви можете отримати джиттер.

Рішення: Якщо міграції корелюють зі стрибками латентності, посиліть афініті або зменшіть крос-ядерні пробудження (thread pools, work stealing).

Завдання 12: Виявити тротлінг (тихий вбивця продуктивності)

cr0x@server:~$ sudo apt-get -y install linux-cpupower >/dev/null
cr0x@server:~$ sudo turbostat --quiet --Summary --interval 1 --num_iterations 3 | head -n 12
     time  cores  CPU%c1  CPU%c6  Avg_MHz  Busy%  Bzy_MHz  TSC_MHz  PkgTmp  PkgWatt
     1.00    24   12.34   45.67     2890   48.2     5120     3600    92.0     210.5
     2.00    24   10.20   40.10     2710   55.0     4920     3600    95.0     225.0
     3.00    24    9.80   35.00     2500   60.1     4580     3600    98.0     230.0

Значення: Температура пакету і споживання ватів високі; Bzy_MHz падає з часом. Часто це — термальне або лімітування потужності під стійким навантаженням.

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

Завдання 13: Профілювати гарячих споживачів CPU (не гадати)

cr0x@server:~$ sudo perf top -p 8812 --stdio --sort comm,dso,symbol | head
Samples: 1K of event 'cpu-clock', Event count (approx.): 250000000
Overhead  Command  Shared Object        Symbol
  18.20%  myapi    myapi                [.] parse_request
  12.50%  myapi    libc.so.6            [.] __memcmp_avx2_movbe
   9.10%  myapi    myapi                [.] serialize_response
   6.70%  myapi    libcrypto.so.3       [.] aes_gcm_encrypt

Значення: Є реальні CPU-гарячі точки. Проблеми гібриду часто проявляються як «раптом CPU-bound», бо нитка опинилася на E-ядрі або була тротлінгнута.

Рішення: Якщо CPU дійсно є вузьким місцем — оптимізуйте. Якщо CPU є «вузьким місцем» лише на E-ядрах — спочатку виправте розміщення.

Завдання 14: Перевірити cgroup CPU-квоти (контейнери можуть саботувати себе)

cr0x@server:~$ systemctl show -p ControlGroup myapi.service
ControlGroup=/system.slice/myapi.service
cr0x@server:~$ cat /sys/fs/cgroup/system.slice/myapi.service/cpu.max
200000 100000

Значення: CPU-квота: 200ms на 100ms період => ефективно 2 CPU часу, незалежно від кількості фізичних ядер.

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

Завдання 15: Kubernetes: перевірити політику CPU Manager і ексклюзивні ядра

cr0x@server:~$ kubectl get node worker-7 -o jsonpath='{.status.nodeInfo.kernelVersion}{"\n"}'
6.5.0-27-generic
cr0x@server:~$ kubectl -n kube-system get cm kubelet-config -o yaml | egrep 'cpuManagerPolicy|reservedSystemCPUs'
cpuManagerPolicy: static
reservedSystemCPUs: "8-15"

Значення: Статичний CPU manager може виділяти ексклюзивні CPU для Guaranteed подів. Системні CPU зарезервовані (тут 8–15).

Рішення: Визначте, які CPU — «системні», а які — «навантяження». На гібриді резервуйте E-ядра для системних демонів, коли можливо, і виділяйте P-ядра для латентних подів.

Завдання 16: Перевірити фактичне виділення CPU для пода

cr0x@server:~$ kubectl describe pod myapi-7f6d7c9d7f-9k2lq | egrep 'QoS Class|Requests|Limits|cpuset'
QoS Class:       Guaranteed
    Requests:
      cpu:     4
    Limits:
      cpu:     4

Значення: Guaranteed pod із рівними request/limit може отримати ексклюзивні CPU під статичною політикою.

Рішення: Підтвердіть, що призначений cpuset на вузлі відповідає P-ядрам. Якщо він потрапив на E-ядра, налаштуйте topology manager / резервні набори CPU.

Швидкий план діагностики

Це послідовність «в мене 15 хвилин до інцидент-бриджу». Мета — не ідеальне розуміння.
Мета — знайти клас вузького місця: насичення P-ядр, неправильне розміщення на E-ядрах, тротлінг або не-CPU обмеження.

Перший крок: вирішіть, чи симптом — латентність, пропускна здатність чи варіативність

• Стрибки латентності (p95/p99): підозрюйте неправильне розміщення, конкуренцію на P-ядрах, тротлінг або підсилення блокувань.
• Падіння пропускної здатності: підозрюйте термальні/потужні ліміти, CPU-квоти або фонову роботу, що краде цикли.
• Варіативність між ідентичними задачами: підозрюйте відмінності в плануванні (P vs E), прив’язки CPU або шумних сусідів.

Другий крок: перевірте, чи P-ядра насичені, а E-ядра простоюють

• Запустіть mpstat -P ALL 1 і шукайте «деякі CPU загрузли, інші простоюють».
• Підтвердіть, які логічні CPU — P, а які — E, використовуючи /sys/devices/system/cpu/*/cpu_capacity.

Якщо P-ядра завантажені, а E-ядра простоюють: ймовірно потрібні виправлення розміщення або налаштування конкурентності.
Якщо всі ядра завантажені: можливо ви просто CPU-bound (або тротлінг).

Третій крок: перевірте тротлінг і поведінку потужності/терміки

• turbostat summary: дивіться на PkgTmp, PkgWatt і зниження Bzy_MHz.
• Шукайте стелі частоти нижче очікуваного через cpupower frequency-info.

Якщо продуктивність падає за хвилини під стійким навантаженням: розцінюйте це як проблему інженерії охолодження/потужності перш за все.
Програмне забезпечення не зможе безкінечно обігнати PL1-ліміт.

Четвертий крок: перевірте cgroup-квоти і прив’язку

• Перевірте cpu.max (cgroups v2) або cpu.cfs_quota_us (v1).
• Перевірте афініті процесів через taskset.

Квоти можуть маскуватися під «гібридну дивину». Прив’язка може в’язати вас у «E-ядерну в’язницю».

П’ятий крок: коротко профілюйте гарячий шлях

• perf top на 30–60 секунд по репрезентативному процесу.
• Якщо ви бачите contention по замках або крипто/стиснення — вирішіть, чи потрібне розміщення на P-ядрах або зміни в коді.

Три корпоративні міні-історії з окопів гібридних CPU

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

Компанія перенесла latency-чутливий API зі старих однорідних серверів на блискучі гібридні машини. Ролоут виглядав безпечним:
використання CPU знизилося, пам’ять була в нормі, перший кендор не показав очевидних помилок.

Потім p99 латентність подвоїлася під піками в будні. Не p50. Не p90. Саме хвіст. Бюджет помилок почав кровоточити тихо, як таблиця Excel, що руйнує.

Он-Калл команда припустила, що «більше ядер» означає «більше запасу». Вони збільшили воркер-треди й підвищили конкурентність. Це покращило середнє і погіршило хвіст.
Класика. Вони нагодували планувальник більшою кількістю runnable-тредів, і планувальник почав розміщувати деякі з них на E-ядрах під навантаженням — особливо ті треди, що прокидалися пізніше й отримували «що вільно» лікування.

Виправлення було нудним і точним: відобразили логічні P-ядра, прив’язали воркери запитів до P-ядр і відгородили фонові сервіси на E-ядра.
Також зменшили надлишкове число воркерів, щоб уникнути вибуху run queue. p99 повернувся до норми, і CPU% почав виглядати «гірше», бо тепер правильні ядра були завантажені.

Справжній урок: якщо ваша модель продуктивності — «ядро як ядро», гібрид покарає вас. Він робить це не злий, а послідовно.

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

Інша команда запускала змішане робоче навантаження: базу даних, агент метрик, лог-форвардер і фоновий індексатор.
Вони помітили, що база іноді потрапляє в CPU-контенцію і вирішили «оптимізувати», прив’язавши базу до фіксованого набору CPU.
Зміна виглядала акуратно. Граф у стейджингу був зелений. Інженер рано пішов додому.

У продакшені затримки запитів поступово погіршувалися протягом тижня. Не різко, а на схилі. БД була прив’язана до CPU 0–11.
На тій конфігурації BIOS CPU 0–7 були P-ядра (чудово), а CPU 8–11 — E-ядра (менш чудово).
Під read-heavy навантаженням фронтальні треди БД залишалися здебільшого на P-ядрах, але деякі важливі фон-реди були застряглі в E-частині набору: чекпойнтери, компакти та кілька працівників обслуговування.

Вони ненавмисно створили розщеплений CPU-світ: частина внутрішніх процесів БД працювала швидко; частина — повільно; повільні іноді тримали блокування й затримували швидкі.
Додаток бачив це як випадковий джиттер.

Відкат виправив ситуацію. Фінальне рішення було більш тонким: прив’язати фронтальні воркери БД до P-ядр, ізолювати галасливі агенти на E-ядра
і лишити гнучкість для фон-воркерів БД використовувати вільний час P-ядр під час вікон техобслуговування. Також додали алерт на глибину run queue для P-ядр (а не просто загальний CPU%).

Урок: прив’язка — це скальпель. Якщо ви користуєтеся ним як молотком — він знайде кістку.

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

Команда зберігання запускала флот build-серверів і кешів артефактів. Навантаження було імпульсним: інтенсивне стиснення й хешування під час збірок,
потім майже проста. Вони взяли гібридні CPU з причини вартості і енергії, але зробили непопулярну річ: перевірили топологію і задокументували її.

Для кожного SKU апаратури вони записали: які логічні CPU відповідають якому типу ядра, типові стійкі частоти під навантаженням і теплову поведінку в стійці.
Також вони підтримували невеликий «відомий добрий» базовий набір ядра й не дозволяли випадковим вузлам дрейфувати.
Це та робота, за яку ніхто не аплодує, бо виглядає як паперова рутина.

Через місяць оновлення прошивки постачальника змінило нумерацію CPU на частині вузлів. Раптом деякі збіркові агенти були прив’язані до неправильних CPU і збірки сповільнилися.
Оскільки в них була job перевірки топології у CI для образу (і проста перевірка при завантаженні), вузли самі помітили «зміну топології» і були автоматично злиті.
Жодного інциденту. Просто тікет і спокійне виправлення.

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

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

1) Симптом: p99-стрибки при «низькому загальному CPU%»

Корінна причина: P-ядра насичені, а E-ядра простоюють; планувальник неправильно розміщує гарячі треди під навантаженням.

Виправлення: Відобразіть P-ядра (за ємністю/частотою), прив’яжіть треди, чутливі до латентності, до P-ядр, відгородіть фоні демони на E-ядра і зменшіть надлишок runnable-тредів.

2) Симптом: ідентичні пакетні задачі сильно різняться в часі виконання

Корінна причина: Деякі задачі виконуються на P-ядрах, інші — на E-ядрах; або cgroup-квоти викликають нерівномірне тротлінгування.

Виправлення: Для пакетних задач пропускної здатності або прийміть варіативність, або явно призначте їх (affinity) на E-ядра. Якщо потрібна справедливість — нормалізуйте шляхом прив’язки до одного класу ядер.

3) Симптом: «Ми оновили CPU, але збірки стали повільніші через 10 хвилин»

Корінна причина: Термічне/потужностне тротлінгування під стійким навантаженням; очікування турбо базувалися на коротких бенчмарках.

Виправлення: Використовуйте turbostat під навантаженням, схожим на продакшен, налаштуйте охолодження/потужність і бенчмаркуйте стійку продуктивність — не тільки короткі сплески.

4) Симптом: Guaranteed-pod в Kubernetes все ще має джиттер

Корінна причина: Ексклюзивні CPU виділені, але це неправильний клас (E-ядра) або вони поділені з IRQ-важкою системною роботою.

Виправлення: Використовуйте CPU manager + topology manager свідомо. Резервуйте E-ядра для системних задач, коли це можливо; виділяйте P-ядра для латентних подів; тримайте IRQ/softirq поза гарячим cpuset.

5) Симптом: Прив’язка «покращила середню латентність, але погіршила хвіст»

Корінна причина: Ви прив’язали фронтальні треди, але залишили фон-турботи, що тримають замки, на E-ядрах — створили повільну контрольну площину для швидкої дата-площини.

Виправлення: Визначте критичні фонові треди (обслуговування БД, GC-помічники), забезпечте їм можливість виконуватись на P-ядрах під піками, або ізолюйте їх у виділені зрізи P-ядр.

6) Симптом: Профілі perf не відповідають реальності

Корінна причина: Треди мігрують між типами ядер; семплінг фіксує іншу поведінку CPU, ніж та, що викликає видиму латентність.

Виправлення: Зменшіть міграції (афініті), профілюйте при стійкому розміщенні й корелюйте вікна профілювання з метриками планувальника і тротлінгу.

7) Симптом: «CPU завантажений», але лише деякі ядра гарячі

Корінна причина: Однониткова вузькість або contention по замках, що виконується на P-ядрах; E-ядра не допомагають, бо вузькість серіалізована.

Виправлення: Зменшіть серіалізацію (lock contention), покращіть паралелізм або збільшіть кількість P-ядр на інстансі. Не кидайте E-ядра на mutex.

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

Крок за кроком: прийняти гібридні CPU, не зруйнувавши латентність

1. Інвентаризуйте топологію в перший день. Записуйте, які логічні CPU — P-ядра, а які — E-ядра за допомогою перевірок ємності/частоти.
   Сприймайте це як конфігурацію, а не як племінне знання.
2. Вирішіть, які навантаження отримують P-ядра. Все на шляху запитів, фронтальні треди БД і критичні IO-треди — за замовчуванням.
3. Відгородіть фонові сервіси. Log shippers, агенти метрик, індексатори, сканери, помічники збірок — перемістіть їх на E-ядра.
4. Перевірте стійку продуктивність. Запустіть тест навантаження на 30–60 хв і дивіться частоту/температуру. Гібрид чутливий до лімітів потужності.
5. Вбивайте оманливі дашборди. Додайте метрики по ядрам або класу ядер: використання P-ядр, використання E-ядр, швидкість міграцій, частота тротлінгу.
6. Робіть прив’язку явною і під рев’ю. Якщо ви використовуєте афініті, кодуйте це в systemd-юнитах або конфігах оркестратора та переглядайте при змінах ядра/прошивки.
7. Репетируйте режими відмов. Що відбувається, коли P-ядра насичуються? Ви знижуєте навантаження, зменшуєте конкурентність або деградуєте плавно?

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

• Підтвердіть, що ядро бачить гібридну топологію (dmesg).
• Підтвердіть мапінг P/E (cpu_capacity або межі частоти).
• Перевірте насичення P-ядр проти простоювання E-ядр (mpstat).
• Перевірте тротлінг (turbostat).
• Перевірте cgroup-квоти (cpu.max).
• Перевірте афініті (taskset, systemd CPUAffinity, kube CPU manager).
• Тільки потім профілюйте код (perf).

Політика-пропозиція: розумна дефолтна стратегія CPU

• Рівень латентності: лише P-ядра, мінімум фонового навантаження, стабільні частоти (в межах вашого бюджету потужності).
• Рівень пропускної здатності: E-ядра переважно, дозволити перелив на P-ядра в поза-пікові години, якщо це не шкодить SLO латентності.
• Системний рівень: зарезервуйте невеликий cpuset для ОС і демонів; бажано E-ядра, якщо їх достатньо, але врахуйте поведінку IRQ/softirq.

Питання та відповіді

1) Чи є E-ядра «повільними ядрами»?

Вони мають нижчу однониткову продуктивність порівняно з P-ядрами, зазвичай. Але вони можуть бути відмінними за пропускною здатністю на ватт, особливо для паралельних навантажень.
Помилка — припускати «ядро як ядро», коли ви робите розрахунок латентності.

2) Чи варто вимикати E-ядра в BIOS для серверів?

Іноді — так. Якщо ваше навантаження суто латентне, ваш стек не може працювати з гетерогенністю або вам потрібно швидко отримати детерміновану поведінку.
Але це грубий інструмент. Спробуйте спочатку ізоляцію і розміщення; вимкнення E-ядр викидає корисну пропускну здатність.

3) Чому «використання CPU» виглядає нормальним, а продуктивність погана?

Бо ємність, яка вам насправді потрібна, може бути P-ядровою. Якщо P-ядра насичені, а E-ядра простоюють, середній CPU% вас обдурить.
Вимірюйте по класу ядра, а не загалом.

4) Чи завжди допомагає прив’язка на гібридних CPU?

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

5) Як знайти, які логічні CPU — P-ядра?

На Linux найпрактичніший підхід — порівняти cpu_capacity (якщо є) та максимальні частоти по ядру через cpupower.
Не покладайтеся на шаблони нумерації без верифікації на конкретному хості.

6) Чи впливають E-ядра на продуктивність сховища?

Можуть. Сховищні стеки часто мають CPU-важкі компоненти (стиск, контрольні суми, шифрування) і роботу, що реагує на переривання.
Якщо IO-completion треди опиняються на E-ядрах, ви можете бачити вищу латентність, навіть якщо диски в нормі.

7) Чи добре/погано SMT (Hyper-Threading) у гібридних системах?

Це залежить від навантаження. SMT може підвищити пропускну здатність, але додати конкуренцію й джиттер для латентних задач.
Гібрид ускладнює це тим, що SMT може бути тільки на P-ядрах, змінюючи сенс «N CPU» у прив’язках і квотах.

8) Як бенчмаркати гібридні CPU?

Бенчмаркуйте з продакшен-подібною конкуренцією, стійкою тривалістю (щоб спіймати тротлінг) і окремими вимірюваннями для:
лише P-ядра, лише E-ядра і змішаного розміщення. Якщо ви запускаєте тільки короткі синтетичні тести, ви переоціните реальну продуктивність.

9) Чи потрібні спеціальні налаштування Kubernetes для гібридних CPU?

Якщо ви запускаєте латентні поди — так: політика CPU manager static, уважно підібрані резервні набори CPU і валідація, що ексклюзивні CPU відповідають P-ядрам.
Інакше ви можете бути «Guaranteed» на папері і опинитися на E-ядрах на практиці.

Висновок: практичні наступні кроки

Гібридні CPU — це не трюк. Це чесний компроміс: більше пропускної здатності на ватт і на площу кристала в обмін на гетерогенність.
У продакшені гетерогенність означає, що треба бути явним щодо розміщення і вимірювання.

1. Виміряйте класи ядер (ємність/частоту) і зберігайте мапу під контролем версій для кожного SKU апаратури.
2. Захистіть гарячий шлях: прив’яжіть або обмежте чутливі до латентності сервіси до P-ядр; відгородіть фонові сервіси на E-ядра.
3. Слідкуйте за тротлінгом під стійким навантаженням; виправляйте охолодження/потужність перед тонким налаштуванням коду.
4. Припиніть довіряти загальному CPU%; інструментуйте насичення P-ядр окремо і налаштуйте алерти на це.
5. Регулярно переглядайте прив’язки після змін BIOS, прошивки та ядра — топологія не є незмінною.

Сделайте ці речі — і гібридні CPU стануть передбачуваними. Ігноруйте — і ви отримаєте перформансну гру «whack-a-mole» з приємнішими технічними характеристиками.