最简捷可靠的方法是使用lscpu命令：执行后查找“L1d cache”“L1i cache”“L2 cache”“L3 cache”四行，分别对应每核独占的一级数据/指令缓存、每核私有二级缓存和全芯片共享三级缓存，单位为KB或MB。
lscpu 输出里怎么看 L1/L2 缓存大小
lscpu 是最直接、最可靠的查看方式，它把缓存信息按层级明确列出，不需解析原始文本。执行后直接找 L1d cache（一级数据缓存）、L1i cache（一级指令缓存）、L2 cache 和 L3 cache 这几行。
常见错误是误以为 cache size 字段来自 /proc/cpuinfo 就代表 L2 —— 实际上该字段在多数 Intel CPU 上显示的是 L3 大小（比如 cache size : 8192 KB），和 lscpu 中的 L3 cache 一致，但完全不反映 L1/L2。
-
L1d cache和L1i cache通常数值相同（如32K），但属于独立缓存单元 -
L2 cache一般是每核独占（per-core），而L3 cache是所有核共享（shared） - 输出单位固定为 KB，如
256K表示 256 KiB，不是十进制千字节
/proc/cpuinfo 里没有 L1/L2 的直接字段
直接 cat /proc/cpuinfo 看不到 L1d cache 这类字段。它只提供 cache size（通常是 L3）、clflush size（缓存行长度）、flags（支持的指令集）等间接信息。
有人试图用 grep -i "cache" /proc/cpuinfo，结果只能看到 cache size 和 clflush size，误判 L2 大小就是白费功夫。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
- 不要依赖
cache size判断 L1 或 L2 —— 它在不同 CPU 厂商/型号下含义不一致 -
clflush size: 64表示缓存行宽度为 64 字节，和缓存总容量无关 - 若需确认是否启用缓存（比如调试内核或虚拟机），应查
flags中的clflush、cdno等标志位
为什么不用 dmidecode 查缓存
dmidecode -t processor 能显示 CPU 型号、主频、插槽信息，但**不包含任何缓存层级细节**。它的输出里只有 Max Speed、Status、Upgrade 等硬件管理字段，L1/L2/L3 一概不列。
运行 dmidecode 还需要 root 权限，且在某些虚拟化环境（如 VMware、KVM）中返回的是模拟值，缓存信息可能缺失或为零。
- 除非你正在排查物理服务器 BIOS 设置或 CPU 插槽兼容性，否则没必要动
dmidecode - 它和缓存容量完全无关，别被 “processor” 类型误导
- 在容器或云主机中，
dmidecode往往根本不可用或返回空
注意多 socket 场景下的 L3 cache 显示逻辑
当机器有多个物理 CPU（Socket(s): 2），lscpu 中的 L3 cache 是单颗 CPU 的 L3 容量，不是总和。例如输出为 L3 cache: 11264K 且 Socket(s): 2，实际总 L3 是 22MB，但每个 CPU 只能直接访问自己那片 11MB。
这点容易被忽略：程序无法跨 socket 高效共享 L3，NUMA 架构下访问远端 L3 延迟显著升高。
-
L1d/L1i/L2都是 per-core，不受 socket 数影响 -
L3 cache值本身不体现共享粒度，需结合NUMA node(s)和Socket(s)综合判断 - 若要验证 NUMA 分布，用
numactl --hardware比只看lscpu更可靠
