我有一个特定的软件，它的失误率看起来像这样：
perf怎么可能呢？
使用<Helmet>
<title>{`Blog | ${name} | ${title}`}</title>
<meta name="title" content={metaTitle} />
<meta name="description" content={metaDesc} />
<meta
property="og:image"
content="https://example.com/images/image.jpg"
/>
<meta
name="keywords"
content="JavaScript, Linter, Linting, Pluggable, Configurable, Code Quality"
/>
<meta
name="description"
content="A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease."
/>
<meta name="theme-color" content="#463fd4" />
<meta property="og:locale" content="en_US" />
<meta
property="og:site_name"
content="ESLint - Pluggable JavaScript linter"
/>
<meta property="og:title" content="require-jsdoc - Rules" />
<meta property="og:url" content="/docs/rules/require-jsdoc" />
<meta property="og:image" content="/assets/img/favicon.512x512.png" />
<meta name="twitter:site" content="@geteslint" />
<meta name="twitter:title" content="require-jsdoc - Rules" />
<meta
name="twitter:description"
content="A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease."
/>
</Helmet>
来计算未命中率，方法是将重新填充计数器除以部分访问每个高速缓存的总访问次数。
答案 0 :(得分：3)
L1-dcache-misses是L1d缓存中所有负载所占的比例。
L2丢失是指完全到达L2的请求（在L1中丢失）和在L2中的 then 未命中的部分。与L3类似。
L1d命中不是L2总访问量的一部分。（之所以有意义，是因为L2从未看到过）。
对于在较小工作集上具有良好局部性的工作负载来说，这是很正常的，但是在L1d中丢失的访问具有时空局部性较差，并且在外部缓存中也往往会丢失。
L1d过滤掉所有“简单”的非常本地访问，而L2和L3仅处理“较难”访问。您可以说L1d的存在是为了为最小的最热工作集提供出色的延迟（和带宽），而L2则试图捕获通过裂缝掉落的东西。然后L3只会看到访问模式中“最困难”的部分。
此外，如果您使用的是Intel CPU，请注意perf不仅使用mem_load_retired.l1_miss事件，依此类推；它尝试使用L1D.REPLACEMENT事件将L1d的 same 行的多个未命中计数为单个未命中。 LLC加载和未加载使用OFFCORE_RESPONSE事件，而不是mem_load_retired.l3_hit /未命中。看到
How does Linux perf calculate the cache-references and cache-misses events
（同一缓存行的两个尚未准备好的负载将共享同一个LFB来跟踪传入的行，因此这种核算是有意义的。同样，如果我们关心的是碰到/丢失的行而不是单个负载。但是{ {1}}使用L1-dcache-loads来计算每个负载，因此，即使是性能报告的L1命中率也不是真正的 每个指令的L1d命中率。 L1d未命中具有空间局部性的任何程序。）