lscpu中L3 cache显示的是整颗CPU的总共享容量，因L3为全核共享资源，而L1d/L1i标的是单核私有容量；/proc/cpuinfo的cache size字段通常等价于L3总量但不可靠，需以lscpu或/sys为准。
直接看 lscpu | grep -i 'l3 cache' 最快，但要注意它显示的是整颗 CPU 的 L3 总容量，不是每核的。
为什么 lscpu 显示的 L3 数值是“总大小”而不是“每核大小”
L3 缓存是所有核心共享的物理资源，lscpu 中的 L3 cache: 12288K 就是这颗 CPU 上全部核心共用的总量（比如 12MB），和核心数无关。这和 L1d/L1i 完全不同——后者标的是单核容量，且每核私有。所以你看到 L1d cache: 32K，不能乘以核心数去算“总 L1”，但对 L3 可以：它本来就是总和。
常见误解是把 /proc/cpuinfo 里的 cache size 当成 L2 或泛指缓存，其实它几乎总是 L3 总量（单位 KB），只是字段名没写清楚。
-
lscpu输出里明确写了L3 cache，优先信这个 -
/proc/cpuinfo中的cache size字段多数情况下等价于 L3，但不保证——某些 ARM 或老平台可能指向别的层级 - 如果
lscpu没输出 L3 行（极少见），说明内核未正确解析该 CPU 的缓存拓扑，得查/sys
当 lscpu 不可信时，怎么从 /sys 手动确认 L3 容量
某些虚拟化环境、旧内核或微码异常（如 Intel Cascade Lake 微码降级后）会导致 lscpu 把 L2 错标为共享，甚至漏掉 L3。这时必须绕过抽象层，直读硬件暴露的 sysfs 接口。
每个逻辑 CPU（如 cpu0）下的 /sys/devices/system/cpu/cpu0/cache/ 目录里，index* 子目录对应一个物理缓存单元。关键不是看名字，而是读内容：
-
cat /sys/devices/system/cpu/cpu0/cache/index*/level—— 值为3的才是 L3 -
cat /sys/devices/system/cpu/cpu0/cache/index*/type—— 应为Unified（L3 是数据+指令统一缓存） -
cat /sys/devices/system/cpu/cpu0/cache/index*/size—— 这个数字就是真实容量（如12288K） -
cat /sys/devices/system/cpu/cpu0/cache/index*/shared_cpu_list—— 若显示0-15，说明是 16 核共享，进一步验证是 L3
注意：不同核心看到的 index* 数量和顺序可能不一致，但只要 level=3 且 shared_cpu_list 覆盖全部逻辑 CPU，就可确认。
dmidecode -t cache 为什么有时不准
sudo dmidecode -t cache 读的是 BIOS/UEFI 固件在 SMBIOS 表中填写的缓存描述，不是运行时探测结果。问题在于：
- 部分厂商固件会把 L3 写成 “Not Installed” 或留空，尤其在启用某些节能特性后
- 虚拟机里通常返回空或默认值（如
Unknown），因为 hypervisor 没透传 SMBIOS cache 条目 - 即使显示
Size: 12288 KB，也无法区分这是 L2 还是 L3，得结合Level字段看——但很多老 BIOS 根本不填这个字段
所以它只适合快速交叉验证，不能作为唯一依据。真要写性能敏感代码（比如手动控制 cache line 对齐或避免 false sharing），必须依赖 lscpu 或 /sys 的实时探测结果。
真正容易被忽略的是：L3 容量 ≠ 运行时可用容量。操作系统、内存映射、NUMA node 绑定、甚至某些安全缓解措施（如 IBRS）都会动态占用部分 L3 空间。如果你在做微基准测试，别只看 lscpu 的数字，还得用 perf stat -e cache-references,cache-misses 实测命中率。
