跨NUMA节点访问内存变慢因远端延迟高、带宽低，并易触发缓存一致性风暴和内存控制器争用；需通过numa_alloc_onnode、MPOL_PREFERRED等策略实现线程与内存同节点绑定。
为什么跨 NUMA 节点访问内存会变慢
因为 CPU 访问本地节点的内存延迟低（约 100ns），而访问远端节点要走 QPI/UPI 链路，延迟翻倍甚至更高，带宽也受限。这不是“慢一点”，而是可能触发缓存一致性协议风暴、加剧内存控制器争用。
常见错误现象：perf stat 显示 LLC-misses 高、remote-dram 计数飙升；numastat 显示进程在 Node 0 分配但大量在 Node 1 上缺页。
- 默认
malloc或new不感知 NUMA，分配位置由内核当前策略决定（通常是 current node） - 线程绑定到 Node 1 的 CPU，但内存仍在 Node 0 分配 → 必然跨节点访问
-
mmap(MAP_ANONYMOUS)默认也不保 locality，除非显式指定MPOL_BIND等策略
如何让 new/malloc 分配本地内存
核心是控制内存分配策略（policy）和绑定（binding），不是靠改代码逻辑，而是靠运行时干预或显式调用 NUMA API。
最直接的方式：用 libnuma 的 numa_alloc_onnode 替代 malloc：
立即学习“C++免费学习笔记（深入）”；
void* ptr = numa_alloc_onnode(size, node_id); // 绑定到指定 node
但注意：C++ operator new 不自动调用它，所以得重载或封装。
- 若用
std::vector，别指望reserve()自动本地化；需配合std::allocator特化，底层调用numa_alloc_onnode - 全局设置策略（如
numactl --membind=1 ./a.out）对malloc有效，但对已加载的共享库或 mmap 区域不一定生效 -
numa_set_localalloc()只影响后续分配，且仅对当前线程有效；多线程必须每个线程都调用
线程与内存节点如何对齐才不踩坑
错位是跨 NUMA 性能问题的主因：线程在 Node 0 CPU 运行，却频繁访问 Node 1 的内存。对齐不是“尽量靠近”，而是“严格绑定+分配同节点”。
典型错误场景：OpenMP 启动 8 个线程，系统自动调度到混合节点的 CPU 上，但所有堆内存都在启动时的 Node 0 分配。
- 用
pthread_setaffinity_np+numa_node_of_cpu获取线程所在 node，再调用numa_set_preferred或numa_alloc_onnode - 避免混用：不要一边用
numactl --cpunodebind=0 --membind=0，另一边又在代码里调用numa_set_interleave_mask，策略会冲突 -
std::thread构造后立即绑定 CPU 和设置内存策略，否则线程可能已在其他 node 上执行了部分初始化代码（包括 global object 构造函数里的 new）
什么时候该用 MPOL_PREFERRED 而不是 MPOL_BIND
MPOL_BIND 强制只从指定节点分配，一旦该节点内存耗尽就 ENOMEM；MPOL_PREFERRED 是 fallback 更友好的策略——优先本地，不足时才跨节点，适合内存用量不确定的服务。
用 mbind 设置已有内存区域策略时，注意范围必须是 page-aligned 且长度是 page size 整数倍：
mbind(ptr, size, MPOL_PREFERRED, &nodemask, maxnode, 0);
-
MPOL_BIND适合固定大小的高性能 buffer（如 DPDK ring、自定义 arena），可控性强 -
MPOL_INTERLEAVE对读密集型随机访问有帮助（分散压力），但写密集时反而增加 coherency traffic，慎用 - 对
mmap区域设策略，必须在mmap后立即调用mbind，且该区域不能已发生缺页（否则策略不生效）
真正难的是动态 workload：内存增长不可控、线程数随负载变化、容器环境节点拓扑不透明。这时候硬编码 node id 或依赖 numactl 参数就容易失效，得结合 numa_node_size64 运行时探测可用性。
