我正在一台有 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。

到目前为止，这是我的结论:

1. 当另一个 NUMA 节点的核心首先接触内存时，mbind() 对内存映射施加的限制仅在 50% 的时间内被阻止。我希望这被记录在某个地方，因为悄悄地违背 promise 并不好......

2. 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/