В Ubuntu 14.04 TLS для 36 суммарных ядер = (2 x ЦП x 9 ядер x 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
Ответы:
Вы не можете изменить распределение ядер между numa-узлами.
Узлы numa - это физические ограничения, связанные с тем, что у вас есть 2 сокета.
Numa - архитектура с неоднородной памятью, имеет штраф за доступ к памяти вне локального узла. Вы должны увидеть, как многопоточные ядра отображаются как «ядра» на том же узле numa, что и основные ядра.
Т.е., если у вас есть 9 ядер / узел numa и вы включили гиперпоточность (в большинстве случаев это не выигрыш в производительности, поскольку гиперпоточные ядра крадут ресурсы у основных ядер, что приводит к большему "перебиванию"), ЕСЛИ ваши гиперпоточные процессы не являются частью та же программа и использует те же части кэша, что и основные ядра. Обычно люди рассматривают ядра как независимые ресурсы, а гиперпоточные ядра также обрабатываются независимо.
Для общих рабочих нагрузок на машинах, которые «загружены», гиперпоточность приведет к увеличению конкуренции за ресурсы и замедлит общую пропускную способность. Если ваша рабочая нагрузка такова, что все основные процессоры и процессоры Hyper-CPU выделены для одной и той же программы и работают с соответствующими потоками, то вы можете получить более высокую производительность с помощью гиперпоточности.
Учитывая ваши вопросы, я бы действительно предложил отключить гиперпоточность, так как не похоже, что вы резервируете 1 узел numa для 1 приложения, где они могут совместно использовать локальную память и ресурсы.
Игнорирование вопроса о гиперпоточности - поскольку это в основном просто дополнительное усложнение при применении тех же правил, вы не можете перемещать процессоры между узлами, поскольку ядро процессора - это также физические объекты, которые физически расположены в одном чипе (узле numa) или другом.
Вы МОЖЕТЕ привязать процессы и потоки к одному узлу numa или другому, используя привязку к процессору - возможно, это то, что вы хотите?
источник