Threadripper 3960x 上的 NPS4 提供了两个完全没有内存的节点

Threadripper 3960x 上的 NPS4 提供了两个完全没有内存的节点

我将 3960x 设置为 NPS4(每插槽节点数:4)模式,以在 Linux 上试验 NUMA。我的系统有 4 个 32 GiB DIMM,分布在 4 个通道上,因此我预计 4 个节点都会得到一个。但结果却是,节点 1 和 2 各得到 64 GiB,节点 0 和 3 得到 0 个:

tavianator@tachyon $ numactl -H
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 24 25 26 27 28 29
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus: 6 7 8 9 10 11 30 31 32 33 34 35
node 1 size: 64342 MB
node 1 free: 4580 MB
node 2 cpus: 12 13 14 15 16 17 36 37 38 39 40 41
node 2 size: 64438 MB
node 2 free: 4276 MB
node 3 cpus: 18 19 20 21 22 23 42 43 44 45 46 47
node 3 size: 0 MB
node 3 free: 0 MB
node distances:
node   0   1   2   3 
  0:  10  12  12  12 
  1:  12  10  12  12 
  2:  12  12  10  12 
  3:  12  12  12  10 

这是预料之中的吗?节点 0/3 核心与内存的距离是否比节点 1/2 核心与内存的距离更远?

答案1

Ryzen 5 3960x 是台式机的一部分。没有像其他产品一样质量的平衡内存指南适用于 EPYC 服务器 CPU在 EPYC 上,内存实际上是以内存通道对为单位的。由于无法找到 Matisse 的通道对,我猜测一半的通道意味着一半的交错集,所以是两个。

尽管它可以创造性地利用其拓扑结构,但这仍然是一个插槽,距离其所有内存只有一跳。更严重的 NUMA 效应直到多个插槽需要相互通信时才会发生。

要查看实际的 NUMA,请购买 2 插槽服务器。但是,您的工作负载可能不需要这样做,AMD 现在制造了一些大型单插槽机箱。

每个插槽 2 个节点可能会产生更合理的拓扑结构。仅用于开发目的,看看它是什么样子。我怀疑这是否会带来明显的性能改进。

生产中的默认设置仍应为 NPS1,除非您有其他数据表明。

答案2

我深入研究了这个问题,学到了很多东西,下面我将进行总结。TLDR:是的,NPS4 NUMA 拓扑似乎是准确的。节点 1/2 的内存访问延迟确实低于节点 0/3。这让我很惊讶,因为我总是看到 3960x/3970x 的图表是这样的:

3960x/3970x 的简化拓扑图

该封装有 4 个 CCD,排列成象限,每个 CCD 有两个 3 核 (3960x) 或 4 核 (3970x) CCX。从该图来看,左侧的两个 CCD 似乎应该可以平等地访问该侧的内存通道。因此,不是像我所想的那样每个 CCD 一个通道,而是两个 CCD 共享两个通道,这使得 NPS2 看起来最合理。

不过,维基芯片显示出一些不对称:

Threadripper 3 拓扑的更详细图表

CCD0(右上)通过 GMI2 链路(红线)连接到 I/O 芯片。紧挨着它的是两个内存控制器(UMC0&1),但它们没有连接到任何内存通道。相比之下,其下方的 CCD2 紧挨着 UMC2/3,它连接到内存通道。可以想象 CCD2 的内存延迟比 CCD1 低。

我们能测量吗?一个工具就是英特尔内存延迟检查器。我们来尝试一下吧!

# tar xf mlc_v3.10.tgz
# sysctl vm.nr_hugepages=4000
vm.nr_hugepages = 4000
# ./Linux/mlc --latency_matrix
Intel(R) Memory Latency Checker - v3.10
malloc(): corrupted top size
[1]    18377 IOT instruction (core dumped)  ./Linux/mlc --latency_matrix

嗯,那好,我们试试先前版本

# tar xf ~/Downloads/mlc_v3.9a.tgz
# sysctl vm.nr_hugepages=4000
vm.nr_hugepages = 4000
# ./Linux/mlc --latency_matrix
Intel(R) Memory Latency Checker - v3.9a
Command line parameters: --latency_matrix 

Using buffer size of 600.000MiB
Measuring idle latencies (in ns)...
                Numa node
Numa node            0       1       2       3
       0        -         98.8   108.1  -
       1        -         93.3   111.9  -
       2        -        112.3    93.2  -
       3        -        107.6    97.9  -

这证实了这一点!同节点延迟约为 93 纳秒,节点 1↔2 延迟约为 112 纳秒,但节点 0↔1 和 2↔3 延迟介于两者之间,约为 98 纳秒。有趣的是,节点 0/3 的最坏情况延迟略好于节点 1/2,约为 108 纳秒。从图表上看,这是有道理的,因为 CCD0 比 CCD2 更接近 UMC4/5。带宽也有类似的情况:

# ./Linux/mlc --bandwidth_matrix
Intel(R) Memory Latency Checker - v3.9a
Command line parameters: --bandwidth_matrix 

Using buffer size of 100.000MiB/thread for reads and an additional 100.000MiB/thread for writes
Measuring Memory Bandwidths between nodes within system 
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
                Numa node
Numa node            0       1       2       3
       0        -       33629.4 31791.2 -
       1        -       34332.5 31419.5 -
       2        -       31193.1 34266.8 -
       3        -       32077.3 33799.3 -

这似乎意味着 3960x(可能还有 3970x)上的一些核心在内存延迟和带宽方面略有优势。我很想知道 3990x 的结果——例如 CCD1 的性能是否与 CCD0 相似?

相关内容