Как я могу изменить распределение ядер по NUMA-узлам?

Question

В Ubuntu 14.04 TLS для 36 ядер всего = (2 х процессоров х 9 ядер х 2 HyperThreading), lscpu дает мне:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                36
On-line CPU(s) list:   0-35
Thread(s) per core:    2
Core(s) per socket:    9
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Stepping:              2
CPU MHz:               1200.000
BogoMIPS:              5858.45
Hypervisor vendor:     Xen
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0-8,18-26
NUMA node1 CPU(s):     9-17,27-35

Как известно, обмен данными между ядрами одного ЦП (через cache-L3) происходит быстрее, чем между ядрами нескольких разных ЦП (через QPI-link).

0-8 и 9-17 - это физические ядра ЦП двух узлов NUMA, но 18-26 и 27-35 - это ядра HyperThreading CPU, и вначале предпочтительнее взять все физические ядра, а затем во втором раунде взять на себя два логических ядра на каждом физическом ядре, то есть это увеличит общую производительность?

Или это означает, что если я запустил более 8 потоков, например, 12 потоков, то 9 потоков (0-8) будут выполняться на 1-м процессоре (NUMA node0) и 3 потока (9-12) на 2-м процессоре (NUMA узел1)? И увеличит ли это задержку обмена между потоками и снизит общую производительность?

Как я могу изменить распределение ядер по NUMA-узлам, чтобы установить, как показано ниже?

NUMA node0 CPU(s):     0-17
NUMA node1 CPU(s):     18-35

Answer 1

Вы не можете изменить распределение ядер между numa-узлами.

Узлы numa - это физические ограничения, связанные с тем, что у вас есть 2 сокета.

Numa - архитектура с неоднородной памятью, имеет штраф за доступ к памяти вне локального узла. Вы должны увидеть, как многопоточные ядра отображаются как «ядра» на том же узле numa, что и основные ядра.

Т.е., если у вас есть 9 ядер / узел numa и вы включили гиперпоточность (обычно это не выигрыш для производительности в большинстве ситуаций, поскольку гиперпоточные ядра крадут ресурсы у основных ядер, что приводит к большему «перебиванию»), ЕСЛИ ваши гиперпоточные процессы не являются частью та же программа и использует те же части кеша, что и основные ядра. Обычно люди относятся к ядрам как к независимым ресурсам, а гиперпоточные ядра также обрабатываются независимо.

Для общих рабочих нагрузок на машинах, которые "загружены", гиперпоточность приведет к увеличению конкуренции за ресурсы и замедлит общую пропускную способность. Если ваша рабочая нагрузка такова, что все основные процессоры и процессоры Hyper-CPU выделены для одной и той же программы и работают с соответствующими потоками, то вы можете получить более высокую производительность с помощью гиперпоточности.

Учитывая ваши вопросы, я бы действительно предложил отключить гиперпоточность, так как не похоже, что вы резервируете 1 узел numa для 1 приложения, где они могут совместно использовать локальную память и ресурсы.

Игнорирование вопроса о гиперпоточности - поскольку это в основном просто дополнительное усложнение при применении тех же правил, вы не можете перемещать процессоры между узлами, поскольку ядро процессора - это также физические объекты, которые физически расположены в одном чипе (узле numa) или другом.

Вы МОЖЕТЕ привязать процессы и потоки к одному узлу numa или другому, используя привязку к процессору - возможно, это то, что вы хотите?