lscpu显示的L1d/L1i/L2数值是每核私有容量，非总和，且不反映共享拓扑；真实缓存布局须查/sys/devices/system/cpu/cpu0/cache/下各index*目录的level、type及shared_cpu_list字段。
lscpu 能快速看到 L1d/L1i/L2/L3 数值，但直接信它显示的数字容易误判缓存实际布局——L1 和 L2 通常是每核私有，L3 才是全核共享；真正要确认归属和拓扑，得查 /sys/devices/system/cpu/cpu0/cache/ 下的具体目录。
为什么 lscpu 显示的 L1 大小不能当总容量用
输出里 L1d cache: 32K 和 L1i cache: 32K 指的是单个逻辑核心的容量，不是整颗 CPU 的总和。比如 16 核 CPU，L1d 总理论容量是 16 × 32K = 512K，但这部分完全隔离，软件无法跨核访问。
- 超线程下两个逻辑核（如
cpu0和cpu1）可能共用同一套 L1d 硬件，lscpu不体现这种分时复用 - 某些旧内核或虚拟机里，
lscpu会把实际每核私有的 L2 错标为“shared”，导致误以为可跨核利用 -
/proc/cpuinfo中的cache size字段几乎总是 L3 总容量（单位 KB），但缺失层级标识，且在部分微码异常场景下（如 Intel Cascade Lake 降级后）可能失真
怎么用 /sys/devices/system/cpu/cpu0/cache/ 精确识别缓存层级
这个路径下的每个 index* 目录对应一个物理缓存单元，靠 level 和 type 文件判断真实归属：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
cat /sys/devices/system/cpu/cpu0/cache/index0/level返回1，且cat /sys/devices/system/cpu/cpu0/cache/index0/type是Data→ 这就是该核心的 L1d -
cat /sys/devices/system/cpu/cpu0/cache/index1/type是Instruction→ 对应 L1i -
cat /sys/devices/system/cpu/cpu0/cache/index2/level返回3，且cat /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list显示0-15→ 这是 16 核共享的 L3 -
coherency_line_size几乎恒为64，即缓存行大小 64 字节，直接影响内存对齐设计和 false sharing 风险
dmidecode -t cache 为什么有时不可靠
这个命令读取 BIOS 提供的缓存描述，但依赖固件正确填充 SMBIOS 表。常见问题包括：
- 多数消费级主板 BIOS 不填 L1/L2 信息，只返回 L3 条目，甚至为空
- 虚拟化环境中（如 KVM/QEMU），
dmidecode可能返回模拟值，与宿主机实际硬件脱钩 - 某些 Intel CPU 在微码更新后重置缓存配置，
dmidecode仍沿用旧表，而/sys/cache/目录反映运行时真实状态
真正做缓存敏感编程（比如手动 prefetch、避免 false sharing、NUMA-aware 内存分配）时，别只看 lscpu 或 /proc/cpuinfo 的数字——必须结合 /sys/devices/system/cpu/cpu*/cache/ 下的 level、type、shared_cpu_list 三者交叉验证，否则容易把私有缓存当成共享资源来调度。
