NUMA и топология CCD Ryzen 9 9950X: как размещение vCPU влияет на задержки.
NUMA и топология CCD Ryzen 9 9950X не равнозначны: гость видит NUMA-схему, но не границы L3. Сравнивать нужно размещение vCPU на одной VM внутри CCD, между CCD и без pinning. Результат зависит от нагрузки, BIOS, ядра, QEMU и SMT.
Как определить, какие vCPU находятся на одном CCD?
Сопоставьте логические CPU с ядрами и SMT-сиблингами, затем найдите группы общего L3-кэша. Каждый CCD объединяет восемь ядер с общим L3, номера CPU зависят от хоста, поэтому проверяйте shared_cpu_list. Запишите BIOS, микрокод, ядро и governor.
lscpu -e=CPU,CORE,SOCKET,NODE,CACHE grep -H . /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list
Границы CCD измеримы: в открытом наборе для 9950X с AGESA 1.2.0.2 средняя задержка CAS через общую строку кэша составила 22,4 нс внутри CCD и 79,5 нс между CCD, тогда как numactl границу не покажет.
От физических ядер к vCPU, emulatorpin и vNUMA
vcpupin связывает vCPU с CPU хоста, но не трогает остальные потоки VM: эмулятор QEMU и IOThread закрепляются отдельно. NUMA node гостя должен отражать домен памяти, а не границу L3, иначе межчиплетная задержка смешается с доступом к удалённой RAM.
virsh vcpupin vm-latency virsh emulatorpin vm-latency virsh numatune vm-latency
Компактный CCD, разнесённые CCD и свободное планирование
Сравните одну VM в трёх конфигурациях: внутри одного L3, между CCD и без vcpupin. Число vCPU и RAM не меняйте, пиннинг задавайте по физическим ядрам, SMT проверяйте отдельно.
Насколько размещение между CCD увеличивает задержку?
Универсальной прибавки нет: результат зависит от общих данных, синхронизации, памяти и миграций. Сравнивайте одну нагрузку на одном хосте, сохраняя p50, p95, p99 и разброс. Core-to-core тест измеряет обмен между CCD, а не p99 приложения.
Как не принять boost, нагрев или соседнюю VM за эффект CCD
Прогрейте VM, фиксируйте частоту, температуру и %st: performance не удерживает частоту на Ryzen. Чередуйте схемы A–B–C–C–B–A и записывайте фоновые задачи. vNUMA должна совпадать с доменами памяти хоста.
Связь задержки с миграциями, кэш-промахами и удалённой памятью
Возьмите приложение с общей памятью или синхронизацией и микротест обмена. Перед серией проверьте pinning в libvirt и память QEMU, затем снимайте context switches, миграции и NUMA faults. Для cache-misses нужен vPMU. Нормируйте счётчики: рост вместе с p99 причину не доказывает.
perf stat -e context-switches,cpu-migrations,cache-misses \ -- ./test numastat -p "$(pgrep -fo 'guest=vm-latency')"
Когда пиннинг vCPU улучшает p99?
1. Рабочие потоки часто обращаются к общим данным.
2. Без pinning они мигрируют между группами L3.
3. p99 снижается без потери throughput и роста %st.
Где компактность помогает, а где ограничивает параллелизм
Сведите три схемы в таблицу: медиана p99 по повторам и доверительный интервал разницы. Если интервал пересекает ноль, результат в пределах погрешности. Задачам с независимыми потоками компактность ничего не даёт: обмена между ядрами почти нет, а привязка сужает выбор планировщика.
Как превратить топологию 9950X в правило эксплуатации
До теста задайте порог, например снижение p99 на 10% без потери ops/s. В XML подставьте cpuset и узел.
<vcpu>2</vcpu> <iothreads>1</iothreads> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <emulatorpin cpuset='2'/> <iothreadpin iothread='1' cpuset='3'/> </cputune> <numatune><memory mode='strict' nodeset='0'/></numatune>
Закрепляйте vCPU внутри CCD только если улучшение p99 воспроизводится в повторных прогонах. Если throughput падает или p99 не меняется, оставьте свободное планирование. Топология задаёт гипотезу, решение зависит от VM.
