lscpu 显示的 l2 cache 值是每核私有容量而非总和或共享容量，误用会导致性能建模和绑核调度错误；真实拓扑需通过 /sys/devices/system/cpu/cpu0/cache/ 下 shared_cpu_list 等字段确认。
lscpu 显示的 L2 cache 值是每核私有容量，不是总和，更不反映共享关系——直接拿它做性能建模或绑核调度，大概率出错。
为什么 lscpu 的 L2 cache 容易误读
它输出的 L2 cache: 256K 是单个物理核心（或超线程对）的私有容量。16 核 CPU 看起来有 16 × 256K = 4MB，但这些 L2 并不互通；两个逻辑核可能共用同一套 L2 硬件，lscpu 不体现这点。常见错误包括：
- 用
lscpu | grep "L2"得到数字后乘以cpu(s)，误以为是总带宽可用空间 - 在 NUMA 调度时假设 L2 可被跨核低延迟访问，结果频繁触发 cache miss 和迁移开销
- 虚拟机里看到
L2 cache: shared，但宿主机实际是 per-core 私有，因 KVM 抽象层做了简化
查真实 L2 大小和拓扑必须读 /sys/devices/system/cpu/cpu0/cache/
这是内核暴露的权威视图，每个 index* 对应一个物理缓存单元，字段不可伪造。实操步骤：
- 先确认 CPU 0 在线：
cat /sys/devices/system/cpu/online，避免读取离线 CPU 的 stale 数据 - 列出所有缓存索引：
ls /sys/devices/system/cpu/cpu0/cache/，通常有index0到index3 - 逐个检查：
cat /sys/devices/system/cpu/cpu0/cache/index*/level找出值为2的项 - 确认类型：
cat /sys/devices/system/cpu/cpu0/cache/indexX/type应为Data、Instruction或Unified - 看大小：
cat /sys/devices/system/cpu/cpu0/cache/indexX/size，单位就是 KB 或 K（如256K） - 关键：查共享范围 ——
cat /sys/devices/system/cpu/cpu0/cache/indexX/shared_cpu_list，若只输出0，说明是纯私有；若输出0,1，说明是两核共享
/proc/cpuinfo 的 l2_cache 字段靠不住
该字段在多数 x86_64 上存在，但行为不稳定：
- ARM 平台或老内核可能把它填成 L1 或 L2，而非标准 L2
- 微码更新后（如 Intel Cascade Lake 降级），
l2_cache可能卡在旧值，dmidecode -t cache有时更准 - 虚拟化环境下，hypervisor 常截断或模拟该字段，和物理硬件脱钩
- 某些内核版本压根不导出
l2_cache，只保留cache size（通常指 L3）
真正影响性能的是缓存行大小（coherency_line_size，几乎总是 64）和共享粒度，不是总容量数字。别跳过 shared_cpu_list 这一步——它才是决定 false sharing 是否发生的实际边界。
