linux下无法直接用命令查出cpu核心间内存访问延迟，因硬件不暴露纳秒级延迟值，需通过memtest86+或自定义c程序结合numactl进行实测。

Linux下无法直接用命令查出具体核心间的内存访问延迟

Linux内核不提供现成命令或接口返回“CPU core A 访问 node B 内存”的纳秒级延迟数值。这不是功能缺失，而是硬件层不暴露该指标——延迟取决于CPU微架构、内存控制器状态、QPI/UPI链路负载、DRAM timing参数等动态因素，且每次访问受cache命中、prefetch、bank冲突等影响极大。所谓“固定延迟值”本身不存在，只有在严格控制的微基准测试中才能测得近似值。

用numactl + memtest86+ 或 custom C程序做跨NUMA节点延迟粗测

真实可行的路径是构造可控访存模式并测量时间差。常见做法有两种：

• 在裸机上用 memtest86+ 启动，其内置“NUMA latency test”会报告各node间相对延迟（单位：cycles），但需重启、不可在运行系统中执行
• 写轻量C程序，绑定线程到特定core，反复读写远端node内存页，并用RDTSC或clock_gettime(CLOCK_MONOTONIC_RAW, ...)采样时间戳。关键点：
  • 必须用numactl --membind=N分配远端内存，否则malloc可能落在local node
  • 要预热内存页（touch each page）并禁用swap（mlock）
  • 单次访问抖动大，需循环数千次取中位数或最小值

示例片段（简化）：

numactl --cpunodebind=0 --membind=1 ./latency_test  # core 0读node 1内存

查NUMA拓扑和内存归属是第一步，不是替代延迟测量

很多人误以为numastat或lscpu能给出延迟，其实它们只告诉你结构关系：

Linux Distros

Linux发行版游乐场，适用于需要临时Linux沙箱、基于浏览器的Linux虚拟机、一次性终端环境、桌面Linux会话等场景

下载

• numactl --hardware 显示每个node有哪些CPU core、多少内存、是否远程
• lscpu | grep -E "NUMA|Socket" 看socket与node映射
• cat /sys/devices/system/node/node*/meminfo 查各node实际已用内存

这些信息帮你判断“哪些core访问哪些内存天然更慢”，但不能告诉你慢多少纳秒——就像知道两地有高速公路，不代表你知道实时车速。

别信“延迟=100ns”这类笼统说法

实测中常见误区是套用文档里的典型值。实际上：

• 同node内L3 cache未命中访问：约40–70 ns
• 跨socket（QPI/UPI）访问远端DRAM：通常120–250 ns，但满载时可能飙到400 ns+
• 若远端node内存被频繁访问导致TLB miss或page fault，延迟会跳变几个数量级

真正影响应用性能的，往往是延迟的方差和尾部延迟（99%ile），而非平均值。这也是为什么数据库、高频交易等场景必须实测，而不是查手册。