必须先执行numactl --hardware确认NUMA节点数量、各节点CPU列表及内存大小，只有输出显示多个node且每个node下cpus和size均非零，才具备跨节点延迟测试前提；否则系统实为UMA模式或NUMA被禁用。
用 numactl --hardware 确认 NUMA 节点布局
物理 CPU 核心之间访问内存的延迟差异，本质是 NUMA 架构下跨 node 访问 vs 本地 node 访问的问题。第一步不是测延迟，而是看清楚你的机器到底有几个 NUMA node、每个 node 绑定哪些 CPU 和内存。
直接运行：numactl --hardware。输出里会列出每个 node 的 CPU 列表（node 0 cpus: 0-7）和内存大小（node 0 size: 65524 MB）。注意：这里的 CPU 编号是逻辑 CPU ID（即 /proc/cpuinfo 中的 processor 字段），不是物理 core ID。
- 如果只看到一个 node，说明你的系统实际是 UMA 模式（或 BIOS 关闭了 NUMA），跨核心延迟差异极小，没必要深究
- 多个 node 且每个 node 下有非零的
cpus和size，才具备测试前提 - 某些虚拟机或容器环境可能屏蔽了 NUMA 信息，
numactl报错或输出不全，此时无法可靠测延迟
用 lat_mem_rd 测量具体 node 间延迟
Linux 内核自带的 lat_mem_rd 工具（属于 linux-tools 或 perf 套件）能直接测量指定 CPU 上读取不同 NUMA node 内存的延迟。它比自己写循环测 rdtsc 更可靠，因为绕过了编译器优化和 cache 干扰。
安装并运行示例：
sudo apt install linux-tools-common linux-tools-$(uname -r) # Debian/Ubuntu sudo yum install perf # RHEL/CentOS sudo perf bench mem memcpy -H # 不推荐，这是带宽测试 # 正确做法： sudo perf bench numa mem --duration 1000 --nproc 1 --thp 0 --membind 0 --cpubind 0,1
但更直接的是用专测延迟的工具：lat_mem_rd（需从 benchmarks 或 numactl 源码编译）。若不可用，退而求其次用 mbw 配合 taskset + numactl 手动隔离：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
taskset -c 0 numactl --membind=0 --cpunodebind=0 dd if=/dev/zero of=/tmp/test bs=1M count=100：本地 node 访问 -
taskset -c 0 numactl --membind=1 --cpunodebind=0 dd if=/dev/zero of=/tmp/test bs=1M count=100：跨 node 访问（CPU 在 node 0，内存强制绑到 node 1） - 用
perf stat -e cycles,instructions,cache-misses包裹上述命令，观察 cycles/cacheline 的差异，比单纯看 wall time 更反映真实延迟
为什么 /proc/cpuinfo 的 core id 和 physical id 不足以判断延迟关系
很多人试图靠 cat /proc/cpuinfo | grep -E "physical id|core id" 推断“哪两个核心离得近”，这是危险的。现代 CPU（尤其是 Xeon Scalable、EPYC）中，同一个 physical id 下的多个 core id 可能分属不同 die，甚至共享 L3 cache 的子集也不完全一致。
关键事实：
-
physical id对应 socket（插槽），不是 NUMA node -
core id是物理核心编号，但不体现互联拓扑（比如 QPI/UPI 链路走向） - 真正决定延迟的是硬件互联路径：同一 die → 同一 socket → 跨 socket（经 QPI/UPI）→ 跨主板（极少）
-
lscpu输出中的NUMA node(s)和NUMA nodeX CPU(s)才是唯一可信依据
容易被忽略的干扰项：TLB、prefetcher 和 transparent huge pages
即使你严格绑定了 CPU 和内存 node，测出的延迟也可能波动极大——常见干扰源不是硬件本身，而是内核和 CPU 微架构行为：
-
/proc/sys/vm/transparent_hugepage/enabled若为always或madvise，会导致内存分配走 THP，掩盖真实 page-level 延迟 - CPU 的硬件 prefetcher（如 Intel 的
DCU prefetcher）会提前加载相邻 cacheline，让顺序访问看起来快得多，但随机访问时失效 - TLB miss 代价远高于 cache miss，尤其在大页未启用时；建议测试前用
numactl --hugepages=...或mmap(MAP_HUGETLB)固定大页 - 避免用
malloc分配内存：它来自glibcheap，位置不可控；改用numactl --membind=N malloc(...)或mbind()系统调用
真正有意义的延迟数据，必须控制内存分配位置、禁用干扰特性、多次采样取中位数——而不是跑一次 time 就下结论。
