lscpu显示的l1缓存大小易误解，因其仅标单核容量（如l1d:32k、l1i:32k），非全cpu总和；多核下l1为每核私有，l3才共享，真实拓扑需查/sys/devices/system/cpu/cpu0/cache/。
Linux 查看 CPU 缓存大小，优先用 lscpu 快速确认，但别只信它显示的数字——L1d/L1i 是每核独立的，L2 通常也是每核私有，L3 才是全核共享；直接读 /sys/devices/system/cpu/cpu0/cache/ 下各 index* 目录才能看到真实拓扑。
为什么 lscpu 显示的 L1 大小容易误解
lscpu 输出里类似 L1d cache: 32K 和 L1i cache: 32K，指的是单个逻辑核心的容量，不是整颗 CPU 的总和。很多人误以为“我的 CPU 有 64K L1”，其实每个核心都独占这 32K 数据 + 32K 指令缓存。
- 多核 CPU（比如 16 核）的 L1 总容量 ≈ 16 × (32K + 32K) = 1024K，但软件无法跨核共享这部分缓存
-
lscpu不体现缓存是否分片、是否按超线程隔离，例如 Intel 的超线程下两个逻辑核可能共用一套 L1d 硬件资源 - 某些老内核或虚拟化环境里，
lscpu可能把 L2 错标为共享（实际是每核私有），这时必须查/sys
怎么用 /sys 精确识别每个缓存层级的归属
/sys/devices/system/cpu/cpu0/cache/ 下的每个 index* 目录对应一个物理缓存单元，level 和 type 文件才是真实依据：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
cat /sys/devices/system/cpu/cpu0/cache/index0/level返回1，且type是Data→ 这就是该核心的 L1d -
cat /sys/devices/system/cpu/cpu0/cache/index1/type是Instruction→ 对应 L1i - 若某个
index2/level是3，且shared_cpu_list显示0-15→ 这是 16 核共享的 L3 -
coherency_line_size几乎总是64，即缓存行大小为 64 字节，影响内存对齐和 false sharing
/proc/cpuinfo 里的 cache size 到底指哪一级
绝大多数 x86_64 CPU 的 /proc/cpuinfo 中 cache size 字段只反映 L3 容量（单位 KB），且是整颗 CPU 的总值，不区分核心数。但它不可靠：
- ARM 或某些嵌入式平台可能根本不写这个字段
- 虚拟机中该值常被 hypervisor 截断或伪造（比如显示 4096K，实际透传的是 16M）
- 没有 L1/L2 的单独字段，无法用于性能调优或缓存敏感编程
- 想确认缓存行大小？看
clflush size或cache_alignment，通常也是64
什么时候必须放弃 lscpu，直接上 dmidecode -t cache
dmidecode -t cache 读取的是 BIOS 固件报告的缓存信息，在以下场景有参考价值：
- 机器刚加电、内核尚未完全初始化缓存拓扑时（如早期 initramfs 阶段）
- 怀疑 CPU 微码更新后缓存配置被重置（例如某些 Intel Cascade Lake 芯片在微码降级后 L3 显示异常）
- 但注意：
dmidecode中的Installed Size可能包含未启用的缓存 bank，而Maximum Size是理论最大值，两者都不等于运行时可用容量
真正做缓存敏感编程（比如手动预取、结构体对齐、避免 false sharing）时，/sys 下的 number_of_sets 和 ways_of_associativity 才决定缓存冲突行为，这些字段 lscpu 根本不暴露。
