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能给出延迟，其实它们只告诉你结构关系：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
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），而非平均值。这也是为什么数据库、高频交易等场景必须实测，而不是查手册。
