Анализ производительности Intel Thread Scheduling

Планировщик потоков операционной системы и механизмы Intel Thread Director определяют, на каком ядре окажется каждый поток в каждый момент времени. Для однородных архитектур прошлого это решение было тривиальным. С появлением гибридных процессоров Core 12-го поколения и серверных Xeon с множеством NUMA-узлов неправильное планирование потоков начало напрямую влиять на производительность: задержки растут, эффективные ядра простаивают, а фоновые задачи занимают ресурсы, нужные критическому пути. В этой статье разобрано, как работает планирование потоков на Intel, как его анализировать и как настраивать для конкретных задач.

Как Intel Thread Director изменил планирование потоков в гибридной архитектуре начиная с Core 12-го поколения

До Alder Lake все ядра в процессоре были одинаковыми, и планировщику ОС не нужно было знать об их различиях. С появлением P-ядер (Performance) и E-ядер (Efficient) возникла принципиально новая задача: операционная система должна понимать, какой поток достаточно важен, чтобы занять P-ядро, а какой можно отправить на E-ядро без потери производительности.

Intel решила эту задачу через аппаратный механизм Thread Director. Он встроен в процессор и непрерывно собирает метрики по каждому потоку: насколько поток нагружает целочисленные блоки, блоки с плавающей запятой, как часто он уходит в ожидание памяти, каковы его паттерны ветвления. На основании этих данных Thread Director классифицирует поток по одному из четырёх классов и передаёт рекомендацию планировщику ОС через специальный регистр.

Windows 11 стала первой ОС, получившей поддержку этого интерфейса. Планировщик Windows 11 читает рекомендации Thread Director и на их основе принимает решение о размещении потока. Linux получил поддержку Intel Thread Director в ядре 6.3 через расширение Energy Aware Scheduling (EAS). До этого Linux распределял потоки по P и E-ядрам без учёта аппаратных рекомендаций, что приводило к субоптимальному использованию гибридной архитектуры.

Четыре аппаратных класса по классификации Thread Director отражают типы исполняемых инструкций. Класс 0 охватывает базовый скалярный код с целочисленными операциями. Класс 1 включает векторные вычисления формата AVX2. Класс 2 выделяется под сверхтяжелые векторные инструкции вроде AVX-512 на серверных процессорах. Класс 3 резервируется для холостых циклов ожидания, состоящих из инструкций Pause или Spin-Wait. Именно потоки третьего класса получают жесткую рекомендацию к переводу на E-ядра для экономии энергии. Важно понимать разграничение зон ответственности: ожидание ввода-вывода и промахи кеша операционная система отслеживает самостоятельно, после чего объединяет собственные метрики с рекомендациями Thread Director для принятия финального решения.

Как планировщик Windows и Linux обрабатывает очереди потоков на гибридных процессорах и где возникают узкие места

Планировщик Windows 11 поддерживает раздельные очереди для P-ядер и E-ядер. Каждый поток имеет базовый приоритет (от 0 до 31) и динамический приоритет, который планировщик корректирует в зависимости от поведения потока. Потоки с приоритетом выше 8 автоматически получают предпочтение на P-ядрах вне зависимости от рекомендации Thread Director.

Проблема возникает в сценарии, когда приложение создаёт большое количество потоков с одинаковым приоритетом. Планировщик распределяет их по всем доступным ядрам, включая E-ядра, и критический путь приложения может оказаться на E-ядре, пока P-ядро занято менее важным фоновым потоком.

Квантование времени (time slice) на P-ядрах в Windows по умолчанию составляет около 15 мс для фоновых процессов и около 30 мс для активного процесса на переднем плане. На E-ядрах значения аналогичны, но сама скорость выполнения кода ниже из-за меньшей тактовой частоты и отсутствия Hyper-Threading на E-ядрах до Meteor Lake.

Linux использует Completely Fair Scheduler (CFS) с расширением EAS для гибридных систем. CFS оперирует понятием vruntime (виртуальное время выполнения): поток с наименьшим vruntime получает следующий квант. На гибридных процессорах EAS добавляет весовые коэффициенты для P и E-ядер, чтобы vruntime учитывал разницу в производительности.

Узкое место в Linux проявляется при использовании cgroups и контейнеров. Если контейнер ограничен по CPU через cpu.shares или cpu.max, планировщик может не учитывать рекомендации Thread Director при распределении квот. Поток оказывается на E-ядре не потому, что это оптимально, а потому что квота CPU исчерпана на P-ядрах.

На серверных Xeon с несколькими сокетами узким местом становится NUMA (Non-Uniform Memory Access). Поток, выполняющийся на ядре сокета 0, но обращающийся к памяти сокета 1, получает дополнительную задержку в 80-120 нс на каждый промах в LLC. Планировщик может мигрировать поток между сокетами в поисках свободного ядра, и каждая такая миграция инвалидирует тепловые данные кеша.

Инструменты для измерения реального поведения планировщика и выявления проблем с распределением потоков

Диагностика начинается с понимания того, на каких именно ядрах выполняются потоки и как часто происходят миграции. Для этого существует несколько инструментов с разным уровнем детализации.

Intel VTune Profiler предоставляет наиболее полную картину для платформ Intel. Анализ Threading показывает временную шкалу активности каждого потока с привязкой к конкретному логическому процессору. Здесь видно, когда поток мигрировал с P-ядра на E-ядро, как долго он ждал в очереди планировщика, и какова была нагрузка на каждое ядро в каждый момент.

vtune -collect threading -knob sampling-interval=1 \
  -result-dir ./results \
  -- ./myapp

vtune -report summary -result-dir ./results
vtune -report timeline -result-dir ./results \
  -format csv -csv-delimiter comma

Анализ Microarchitecture Exploration в VTune добавляет метрики Thread Director: показывает, в какой класс классифицировался каждый поток и совпала ли рекомендация с реальным размещением.

На Linux основным инструментом является perf. Событие sched:sched_migrate_task фиксирует каждую миграцию потока между ядрами:

perf record -e sched:sched_migrate_task \
  -e sched:sched_switch \
  -e sched:sched_wakeup \
  -ag -- sleep 30

perf script | grep migrate | head -50

perf report --sort=cpu,comm,pid

Высокая частота миграций (более 1000 в секунду для одного потока) указывает на то, что планировщик не может найти стабильное место для потока. Это может быть следствием неправильно выставленных приоритетов, конкуренции с другими процессами или слишком агрессивной балансировки нагрузки.

turbostat показывает загрузку и частоты на каждом ядре в реальном времени:

sudo turbostat --interval 1 \
  --show Core,CPU,Avg_MHz,Busy%,Bzy_MHz,TSC_MHz,C1,C6

Это позволяет увидеть, действительно ли P-ядра работают на буст-частоте, пока E-ядра простаивают, или планировщик неправильно распределил нагрузку и все ядра работают ниже оптимальной частоты.

Для Windows аналогом служат Windows Performance Analyzer (WPA) и ETW-трассировка:

wpr -start CPU -start DiskIO -filemode
Start-Sleep 30
wpr -stop C:\trace.etl

# Открыть в Windows Performance Analyzer
wpa C:\trace.etl

В WPA граф "CPU Usage (Precise)" показывает timeline каждого потока с указанием, на каком процессоре он выполнялся, и длительность каждого кванта.

Настройка thread affinity для закрепления критических потоков за конкретными ядрами

Thread affinity позволяет явно указать, на каких логических процессорах может выполняться поток или процесс. Это наиболее прямой способ гарантировать, что критический поток всегда окажется на P-ядре, и что он не будет мигрировать, разрушая тепловые данные кеша.

На Linux закрепление процесса за ядрами выполняется через taskset:

# Показать текущую маску affinity
taskset -cp $$

# Закрепить процесс за P-ядрами (0-7 на Core i9-13900K)
taskset -cp 0-7 PID

# Запустить новый процесс с affinity
taskset -c 0-7 ./myapp

# Через cpuset в cgroups
mkdir /sys/fs/cgroup/cpuset/critical
echo "0-7" > /sys/fs/cgroup/cpuset/critical/cpuset.cpus
echo "0" > /sys/fs/cgroup/cpuset/critical/cpuset.mems
echo PID > /sys/fs/cgroup/cpuset/critical/tasks

Чтобы знать, какие логические процессоры соответствуют P-ядрам, нужно прочитать топологию:

cat /sys/devices/system/cpu/cpu*/topology/core_type 2>/dev/null

lscpu --extended

# На Alder Lake и новее ядра типа Core (P) обозначены как "core"
# ядра типа Atom (E) обозначены как "atom"
grep -r "core_type" /sys/devices/system/cpu/cpu*/topology/

В коде на C/C++ affinity устанавливается через pthread_setaffinity_np на Linux и SetThreadAffinityMask на Windows:

// Linux
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(0, &cpuset);
CPU_SET(2, &cpuset);
CPU_SET(4, &cpuset);

pthread_t thread = pthread_self();
pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);

// Windows
DWORD_PTR mask = 0x55; // биты 0,2,4,6 = логические процессоры P-ядер
SetThreadAffinityMask(GetCurrentThread(), mask);

Закрепление потока за конкретными ядрами имеет обратную сторону. Если закреплённый поток заблокировался (ждёт I/O или мьютекс), назначенные ядра простаивают, тогда как незакреплённые потоки не могут ими воспользоваться. Поэтому закрепление оправдано только для вычислительно-интенсивных потоков с высоким CPU-утилизацией, которые редко блокируются.

Управление приоритетами потоков через планировщик и как это взаимодействует с Thread Director

Приоритеты потоков влияют на то, какой поток получит следующий квант времени при конкуренции за ядро. Это отдельный механизм от affinity, и они работают вместе.

На Linux приоритет потока определяется двумя параметрами: политикой планировщика (SCHED_OTHER, SCHED_FIFO, SCHED_RR, SCHED_BATCH, SCHED_IDLE) и значением nice (от -20 до 19 для SCHED_OTHER).

# Показать текущий приоритет и политику
chrt -p PID

# Установить realtime-приоритет (SCHED_FIFO)
sudo chrt -f -p 50 PID

# Установить nice-значение
renice -n -10 -p PID

# Запустить с пониженным приоритетом (фоновые задачи)
nice -n 15 ./background_task

SCHED_FIFO и SCHED_RR являются realtime-политиками. Поток с SCHED_FIFO не вытесняется другими потоками с более низким приоритетом и не уступает квант добровольно до тех пор, пока не заблокируется. Это мощный инструмент для задач с жёсткими требованиями к задержке, но при неправильном использовании он блокирует все остальные потоки на ядре, включая системные.

На Windows приоритеты работают иначе. Базовый приоритет потока определяется классом приоритета процесса и относительным приоритетом потока внутри процесса:

// Установить класс приоритета процесса
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);

// Установить приоритет конкретного потока
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST);

// Для критических realtime-задач
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

Взаимодействие приоритетов с Thread Director проявляется в том, что Thread Director предоставляет рекомендацию по типу ядра, а приоритет определяет порядок доступа к этому ядру. Поток с высоким приоритетом и рекомендацией на P-ядро получит P-ядро первым. Поток с низким приоритетом и той же рекомендацией будет ждать, пока P-ядро освободится.

Настройка NUMA-affinity для серверных Xeon и минимизация межузловых обращений к памяти

На серверных системах с несколькими сокетами NUMA-топология определяет стоимость доступа к памяти. Каждый сокет имеет локальную память с задержкой около 80 нс и удалённую память соседнего сокета с задержкой 130-160 нс. Для вычислительно-интенсивных задач с интенсивным доступом к памяти эта разница может составлять 15-25% производительности.

Первый шаг это понимание топологии системы:

numactl --hardware

numactl --show

lstopo --of txt

cat /sys/devices/system/node/node*/cpumap

numactl позволяет запустить процесс с явной привязкой к NUMA-узлу:

# Запустить на узле 0, память только с узла 0
numactl --cpunodebind=0 --membind=0 ./myapp

# Запустить на узлах 0 и 1, память только с узла 0
numactl --cpunodebind=0,1 --membind=0 ./myapp

# Интерливинг памяти между узлами (для равномерной нагрузки)
numactl --interleave=all ./myapp

В коде управление NUMA-аллокацией осуществляется через libnuma:

#include <numa.h>

// Аллоцировать память на конкретном узле
void* ptr = numa_alloc_onnode(size, node_id);

// Переместить существующие страницы на нужный узел
numa_migrate_pages(pid, from_mask, to_mask);

// Установить политику для текущего потока
struct bitmask* mask = numa_allocate_nodemask();
numa_bitmask_setbit(mask, 0);
numa_set_membind(mask);

Политика numactl --interleave распределяет страницы памяти равномерно между узлами. Это оправдано для рабочих нагрузок, где потоки обращаются к данным случайным образом и нет чёткой локальности, например при обработке больших баз данных in-memory.

На Windows управление NUMA осуществляется через SetThreadIdealProcessor и VirtualAllocExNuma:

// Аллоцировать память на конкретном NUMA-узле
void* ptr = VirtualAllocExNuma(
    GetCurrentProcess(),
    nullptr,
    size,
    MEM_COMMIT | MEM_RESERVE,
    PAGE_READWRITE,
    numa_node
);

// Установить предпочтительный процессор для потока
SetThreadIdealProcessor(thread_handle, processor_number);

Диагностику NUMA-проблем удобно выполнять через perf stat с event-ами для удалённого доступа к памяти:

perf stat -e \
  node-loads,node-load-misses,\
  node-stores,node-store-misses \
  -p PID sleep 10

Высокое соотношение node-load-misses к node-loads указывает на то, что потоки часто обращаются к удалённой памяти. Следующий шаг это определить, какие именно потоки вызывают эти обращения, через VTune с анализом Memory Access.

Как настроить планировщик для встроенных систем и задач с жёсткими требованиями к задержке

Для встраиваемых систем и задач реального времени на базе Intel требования принципиально иные. Здесь важна не пропускная способность, а детерминированная задержка: поток должен получить ядро в течение строго определённого времени после пробуждения.

Первый шаг для достижения низкой задержки это изоляция ядер от планировщика общего назначения. isolcpus в параметрах ядра Linux исключает указанные ядра из пула планировщика:

# В /etc/default/grub добавить в GRUB_CMDLINE_LINUX:
# isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3

# После изменения:
update-grub
reboot

# Проверить изоляцию:
cat /sys/devices/system/cpu/isolated

После изоляции ядра 2 и 3 не получают никаких потоков от планировщика, пока поток явно не закреплён на них через affinity. На изолированных ядрах также отключаются прерывания таймера (nohz_full), что устраняет jitter от периодических прерываний.

IRQ-affinity определяет, какие ядра обрабатывают аппаратные прерывания. По умолчанию прерывания распределяются по всем ядрам, что вызывает непредсказуемые задержки на ядрах с realtime-потоками:

# Показать текущее распределение IRQ
cat /proc/interrupts

# Закрепить все прерывания на ядро 0 (оставив 2,3 чистыми)
for IRQ in $(ls /proc/irq/); do
    echo 1 > /proc/irq/$IRQ/smp_affinity 2>/dev/null
done

# Или через irqbalance с исключением ядер
IRQBALANCE_BANNED_CPUS=0xC irqbalance

cyclictest измеряет реальную задержку пробуждения потоков и является стандартным инструментом валидации realtime-конфигурации:

sudo cyclictest \
  --mlockall \
  --smp \
  --priority=80 \
  --interval=200 \
  --distance=0 \
  --affinity=2,3 \
  --duration=5m \
  --histogram=400 \
  --histfile=latency.txt

# Визуализация гистограммы
gnuplot -e "
set terminal png;
set output 'latency.png';
plot 'latency.txt' using 1:2 with lines title 'Core 2',
     'latency.txt' using 1:3 with lines title 'Core 3'
"

Значения максимальной задержки ниже 50 мкс считаются хорошим результатом для систем без RT-ядра Linux. С патчсетом PREEMPT_RT типичный максимум снижается до 20-30 мкс. Intel рекомендует использовать ядра Linux с PREEMPT_RT для систем на базе Xeon с требованиями к задержке ниже 100 мкс.

Для встраиваемых систем на базе Intel Atom и Core Ultra с малым энергопотреблением дополнительную роль играет управление C-состояниями. Выход из глубокого сна (C6, C7) добавляет задержку в 100-300 мкс, что недопустимо для realtime-задач:

# Ограничить C-состояния через cpupower
sudo cpupower idle-set --disable-by-latency 10

# Или через параметр ядра
# добавить в GRUB_CMDLINE_LINUX: processor.max_cstate=1 intel_idle.max_cstate=0

# Проверить текущие C-состояния
cpupower monitor -m Idle_Stats

Отключение глубоких C-состояний увеличивает энергопотребление в простое, но гарантирует, что ядро всегда готово к немедленному выполнению потока без задержки на выход из сна.