我正在一台有 4 个 Operton 6272 处理器、运行 centOS 的机器上试验 NUMA。有8个NUMA节点,每个节点有16GB内存。
这是我正在运行的一个小测试程序。
void pin_to_core(size_t core)
{
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(core, &cpuset);
pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset);
}
int main()
{
pin_to_core( 0 );
size_t bufSize = 100;
for( int i = 0; i < 131000; ++i )
{
if( !(i % 10) )
{
std::cout << i << std::endl;
long long free = 0;
for( unsigned j = 0; j < 8; ++j )
{
numa_node_size64( j, &free );
std::cout << "Free on node " << j << ": " << free << std::endl;
}
}
char* buf = (char*)numa_alloc_onnode( bufSize, 5 );
for( unsigned j = 0; j < bufSize; ++j )
buf[j] = j;
}
return 0;
}
所以基本上,在核心 #0 上运行的线程在 NUMA 节点 5 上分配 131K 100 字节缓冲区,用垃圾初始化它们并泄漏它们。每 10 次迭代,我们打印出有关每个 NUMA 节点上有多少可用内存的信息。
在输出的开头我得到:
0
Free on node 0: 16115879936
Free on node 1: 16667398144
Free on node 2: 16730402816
Free on node 3: 16529108992
Free on node 4: 16624508928
Free on node 5: 16361529344
Free on node 6: 16747118592
Free on node 7: 16631336960
...
最后我得到:
Free on node 0: 15826657280
Free on node 1: 16667123712
Free on node 2: 16731033600
Free on node 3: 16529358848
Free on node 4: 16624885760
Free on node 5: 16093630464
Free on node 6: 16747384832
Free on node 7: 16631332864
130970
Free on node 0: 15826657280
Free on node 1: 16667123712
Free on node 2: 16731033600
Free on node 3: 16529358848
Free on node 4: 16624885760
Free on node 5: 16093630464
Free on node 6: 16747384832
Free on node 7: 16631332864
mbind: Cannot allocate memory
mbind: Cannot allocate memory
mbind: Cannot allocate memory
mbind: Cannot allocate memory
mbind: Cannot allocate memory
mbind: Cannot allocate memory
mbind: Cannot allocate memory
130980
...
我不清楚的地方:
1) 为什么会出现“mbind:无法分配内存”消息?事实上,我还远未用完所有内存,而且如果我将缓冲区大小更改为 1000,行为也不会改变,这让我认为我快用完了某种内核资源句柄.
2) 尽管我要求在节点 5 上分配内存,但实际分配似乎已在节点 0 和 5 之间分配。
谁能对发生这种情况的原因给出任何见解?
更新
想就第 (2) 点提供更多详细信息。某些内存未分配到节点 5 的事实似乎与我们正在核心 #0(属于 NUMA 节点 0)上初始化缓冲区这一事实有关。如果我将 pin_to_core(0)
更改为 pin_to_core(8)
,则分配的内存将在节点 1 和 5 之间分配。如果是 pin_to_core(40)
那么所有的内存都分配在节点 5 上。
更新 2
我查看了 libnuma 的源代码并尝试用来自那里的更多低级调用替换对 numa_alloc_onnode()
的调用:mmap()
和 mbind()
。我现在还在检查内存驻留在哪个 NUMA 节点上 - 我为此使用了 move_pages()
调用。结果如下。在初始化之前(在 j
上循环)页面没有映射到任何节点(我得到 ENOENT 错误代码)并且在初始化之后页面被分配给节点 0 或节点 5。模式是规则的: 5,0,5,0,... 和以前一样,当我们接近第 131000 次迭代时,对 mbind()
的调用开始返回错误代码,当这种情况发生时,页面是总是分配给节点 0。mbind 返回的错误代码是 ENOMEM,文档说这意味着“内核内存”用完了。我不知道它是什么,但它不可能是“物理”内存,因为我每个节点有 16GB。
到目前为止,这是我的结论:
当另一个 NUMA 节点的核心首先接触内存时,
mbind()
对内存映射施加的限制仅在 50% 的时间内被阻止。我希望这被记录在某个地方,因为悄悄地违背 promise 并不好......mbind
的调用次数有限制。因此,应该尽可能mbind()
大内存块。
我要尝试的方法是:在固定到特定 NUMA ndo 核心的线程上执行内存分配任务。为了更加安心,我会尝试调用 mlock(因为描述的问题 here )。
最佳答案
正如您通过阅读 libnuma.c
发现的那样,每次调用 numa_alloc_onnode()
都会创建一个新的匿名内存映射,然后将内存区域绑定(bind)到指定的 NUMA节点。如此多次调用 mmap()
,您只是达到了每个进程允许的最大内存映射数。该值可以从 /proc/sys/vm/max_map_count
中读取,也可以由系统管理员通过写入伪文件来修改:
# echo 1048576 > /proc/sys/vm/max_map_count
或使用sysctl
:
# sysctl -w vm.max_map_count=1048576
许多 Linux 发行版的默认设置是 65530
映射。 mmap()
实现映射合并,即它在创建新映射之前首先尝试扩展现有映射。在我的测试中,它会在每隔一次调用时创建一个新映射,否则会扩展前一个映射。在第一次调用 numa_alloc_onnode()
之前,我的测试进程有 37 个映射。因此 mmap()
应该在 2 * (65530-37) = 130986
调用之后的某处开始失败。
看起来当 mbind()
应用于现有映射的一部分时,会发生一些奇怪的事情,新受影响的区域没有正确绑定(bind)。我必须深入内核源代码才能找出原因。另一方面,如果您替换:
numa_alloc_onnode( bufSize, 5 )
与
numa_alloc_onnode( bufSize, i % 4 )
没有执行映射合并,mmap()
在第 65500 次迭代附近失败,所有分配都正确绑定(bind)。
关于c++ - 使用 numa_alloc_onnode() 分配小块有限制吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19656993/