当所有 lscpu 显示 4 个 numa 节点时,使用 --membind=1 或 3 理解失败的 numactl

问题描述

我一直试图找出 numactl 命令失败的问题,但看起来我可能不完全理解 numactlOMP_MP_THREAD 的工作方式。

我正在尝试使用 main.py 运行绑定到 numa-node-1 的 4 个 cpu 的 1 个实例的脚本 numactl --physcpubind=24-27 --membind=1 python -u main.py,因为 lscpu 显示绑定到的 cpu 24-27 numa-node-1。

但我收到以下错误

libnuma: Warning: node argument 1 is out of range
<1> is invalid

如果我使用 --membind=3 我会得到同样的错误,但是当我使用 --membind=2 时它会运行。

问题:

1.对于 numa-node=0,0-23,96-119 个物理内核中的每个是 0-23 个,或者只有 0-23 个中的一些是物理内核,因为有 2 个每个核心线程?如何知道“0-23,96-119”中哪些是第二个线程?

2. 我是否正确地将 phys-core 绑定到节点?为什么会出现上述失败?

3.哪些 2 numa 节点在 socket-0 上,哪些在 socket-1 上?

输出

lscpu

Architecture:                    x86_64
cpu op-mode(s):                  32-bit,64-bit
Byte Order:                      Little Endian
Address sizes:                   46 bits physical,48 bits virtual
cpu(s):                          192
On-line cpu(s) list:             0-191
Thread(s) per core:              2
Core(s) per socket:              48
Socket(s):                       2
NUMA node(s):                    4
vendor ID:                       GenuineIntel
cpu family:                      6
Model:                           85
Model name:                      Intel(R) Xeon(R) Platinum 9242 cpu @ 2.30GHz
Stepping:                        7
Frequency boost:                 enabled
cpu MHz:                         1000.026
cpu max MHz:                     2301,0000
cpu min MHz:                     1000,0000
BogoMIPS:                        4600.00
L1d cache:                       3 MiB
L1i cache:                       3 MiB
L2 cache:                        96 MiB
L3 cache:                        143 MiB
NUMA node0 cpu(s):               0-23,96-119
NUMA node1 cpu(s):               24-47,120-143
NUMA node2 cpu(s):               48-71,144-167
NUMA node3 cpu(s):               72-95,168-191

numactl --hardware:

available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
node 0 size: 64106 MB
node 0 free: 28478 MB
node 1 cpus: 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143
node 1 size: 0 MB
node 1 free: 0 MB
node 2 cpus: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167
node 2 size: 64478 MB
node 2 free: 45446 MB
node 3 cpus: 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
node 3 size: 0 MB
node 3 free: 0 MB
node distances:
node   0   1   2   3 
  0:  10  21  21  21 
  1:  21  10  21  21 
  2:  21  21  10  21 
  3:  21  21  21  10 

解决方法

这里的问题是您的某些 NUMA 节点未填充任何内存。您可以看到 numactl --hardware 命令的输出显示节点 1 和 3 上的内存大小为 0。因此,尝试将内存绑定到这些节点是一场失败的战斗......

旁注:9242 CPU 通常(好吧,AFAIK)仅可用于焊接内存模块,因此您的机器上不太可能缺少内存 DIMM。因此,要么您的机器的硬件级别存在严重问题,要么存在某种类型的虚拟化层,它对您隐藏了部分内存。无论哪种方式,配置都非常错误,需要深入调查。

编辑:回答额外的问题

  1. 物理内核与硬件线程编号:启用超线程后,不再有物理内核的实际编号。操作系统看到的所有内核实际上都是硬件线程。简单地说,在您的情况下,物理核心 0 被视为 2 个逻辑核心 0 和 96。物理核心 1 被视为逻辑核心 1 和 97,依此类推...

  2. Numactl 失败:已经回答

  3. NUMA节点编号:一般来说,取决于机器的BIOS。因此,当您在每个具有 P 个内核的节点上有 N 个物理插槽时,有 2 个主要的编号选项。这两个选项如下(命名是我的,不确定是否有官方的):

    1. 传播:
      • 插槽 0:核心 0、N、2N、3N、...、(P-1)N
      • 插槽 1:内核 1、N+1、2N+1、...、(P-1)N+1
      • ...
      • 插槽 N-1:内核 N-1、2N-1、...、PN-1
    2. 线性:
      • 插槽 0:内核 0、1、...、P-1
      • 插槽 1:核心 P、P+1、...、2P-1
      • ...
      • 插槽 N-1:内核 (N-1)P、...、NP-1

    如果启用了超线程,您只需为每个插槽添加 P 个内核,并对其进行编号,以便编号为 C 和 C+PN 的内核实际上是同一物理内核的 2 个硬件线程。

    在这里,您看到的是线性编号

  4. numactl --physcpubind=0-3:这限制了您启动的命令允许调度到传入参数的列表中的逻辑核心范围,即核心 0、1、2 和 3。但这不会t 强制您启动的代码一次使用多个内核。对于 OpenMP 代码,您仍然需要为此设置 OMP_NUM_THREADS 环境变量。

  5. OMP_NUM_THREADS 和 HT:OMP_NUM_THREADS 只说明要启动的线程数,它不关心内核是物理的还是逻辑的。

  6. numactl 报告的距离:我不太确定报告值的确切含义/准确性,但这是我在需要时解释它们的方式:对我而言,它对应于某些相对内存访问延迟。我不知道这些值是测量出来的还是只是猜测,以及这些是周期还是纳秒,但它是这样说的:

    • 来自 NUMA 节点 0 的内核对连接到 NUMA 节点 0 的内存的访问延迟为 10,对所有其他 NUMA 节点的访问延迟为 21
    • 来自 NUMA 节点 1 的内核对连接到 NUMA 节点 1 的内存的访问延迟为 10 个,对所有其他 NUMA 节点的访问延迟为 21 个

    • 但关键是访问远程内存比访问本地内存长2.1倍