私はいくつかのアルゴリズムでいくつかのベンチマークを実行し、それらのメモリ使用量と効率（L1 / L2 / TLBアクセスとミス）をプロファイリングしてきましたが、結果のいくつかは私にとって非常に興味深いものです。
包括的キャッシュ階層（L1およびL2キャッシュ）を考慮すると、L1キャッシュミスの数はL2キャッシュアクセス の数と一致するべきではありませんか？私が見つけた説明の1つは、TLBに関連するものです。仮想アドレスがTLBにマップされていない場合、システムは一部のキャッシュレベルでの検索を自動的にスキップします。これは合法だと思いますか？
まず、包括的キャッシュ階層は、想定しているほど一般的ではない場合があります。たとえば、現在のIntelプロセッサ（Nehalem、Sandybridge、場合によってはAtoms）には、L2に含まれるL1が含まれているとは思いません。（ただし、NehalemとおそらくSandybridgeには、L1とL2の両方がL3に含まれています。Intelの現在の用語であるLLCのFLCとMLCを使用しています。）
しかし、これは必ずしも重要ではありません。ほとんどのキャッシュ階層では、L1キャッシュミスがある場合、そのミスはおそらくL2で検索されます。包括的であるかどうかは関係ありません。そうしないと、気になるデータが（おそらく）L2にないことを伝える何かが必要になり、調べる必要はありません。これを行うプロトコルとメモリタイプを設計しましたが、たとえば、L1でのみキャッシュされ、L2ではキャッシュされないメモリタイプは、L1で組み合わせる利点が得られるグラフィックスなど、繰り返しスキャンする場合に役立ちます。配列が大きいため、L2にキャッシュすることはお勧めできません。ビット私は現時点で誰かがそれらを出荷していることを知りません。
とにかく、L1キャッシュミスの数がL2キャッシュアクセスの数と等しくない可能性があるいくつかの理由があります。
作業しているシステムはわかりません。私の答えは、NehalemやSandybridgeなどのIntel x86に当てはまると思います。これらのEMONパフォーマンスイベントモニタリングでは、L1やL2のキャッシュミスなどをカウントできます。また、ARMやPowerのような、キャッシュミス用のハードウェアパフォーマンスカウンターを備えた最新のマイクロプロセッサーにも適用されます。
最近のほとんどのマイクロプロセッサは、最初のキャッシュミスで停止しませんが、余分な作業を続けようとします。これは全体的に投機的実行と呼ばれることがよくあります。さらに、プロセッサは順不同または順不同の場合がありますが、後者の場合、L1ミスの数とL2アクセスの数の差がさらに大きくなる可能性がありますが、必須ではありません。この動作は、インオーダーでも発生します。プロセッサを注文します。
簡単な答え：これらの投機的なメモリアクセスの多くは、同じメモリ位置になります。それらは押しつぶされて結合されます。
パフォーマンスイベント「L1キャッシュミス」は、おそらく[*] L1キャッシュをミスした（投機的）命令の数をカウントしています。次に、Intelでフィルバッファと呼ばれるハードウェアデータ構造を、他のいくつかの場所でミスステータス処理レジスタに割り当てます。同じキャッシュラインに対する後続のキャッシュミスは、L1キャッシュをミスしますが、フィルバッファーにヒットし、押しつぶされます。それらのうちの1つだけ、通常は最初のものがL2に送信され、L2アクセスとしてカウントされます。）
ちなみに、これにはパフォーマンスイベントが発生する可能性があります：Squashed_Cache_Misses。
パフォーマンスイベントL1_Cache_Misses_Retiredも発生する可能性があります。ただし、推測によってデータがキャッシュに取り込まれる可能性があり、リタイア時にキャッシュミスが発生することはないため、これは過小評価される可能性があります。
（[*]ちなみに、ここで「たぶん」と言うときは、「設計を手伝ったマシンで」という意味です。ほぼ間違いなく、定義を確認してRTLを確認する必要があるかもしれませんが、ほぼ保証されています。）
たとえば、バイトA [0]、A [1]、A [2]、... A [63]、A [64]、..にアクセスしていると想像してください。
A [0]のアドレスが64を法としてゼロに等しい場合、A [0] .. A [63]は、64バイトのキャッシュラインを持つマシンの同じキャッシュラインにあります。これらを使用するコードが単純な場合、それらすべてが投機的に発行される可能性は十分にあります。QED：64の投機的メモリアクセス、64のL1キャッシュミス、ただし1つのL2メモリアクセスのみ。
（ちなみに、数値がそれほどクリーンであるとは期待しないでください。L2アクセスごとに正確に64のL1アクセスを取得できない場合があります。）
さらにいくつかの可能性：
L2アクセスの数がL1キャッシュミスの数よりも多い場合（私はほとんど見たことがありませんが、可能です）、ハードウェアプリフェッチャーを混乱させるメモリアクセスパターンがある可能性があります。ハードウェアプリフェッチャーは、必要なキャッシュラインを予測しようとします。 プリフェッチャーの予測が悪い場合、実際には必要のないキャッシュラインをフェッチする可能性があります。 多くの場合、Prefetches_from_L2またはPrefetches_from_Memoryをカウントするパフォーマンスがあります。
一部のマシンは、L2に送信される前に、L1キャッシュミスの原因となった投機的アクセスをキャンセルする場合があります。しかし、私はIntelがこれを行っていることを知りません。
データキャッシュの書き込みポリシーは、ストアヒットがデータをそのキャッシュにのみ書き込むか（ライトバックまたはコピーバック）、キャッシュ階層の次のレベルに書き込むか（ライトスルー）を決定します。したがって、ライトスルーL1-Dキャッシュにヒットしたストアは、そのデータもL2キャッシュに書き込みます。
これは、L1キャッシュミスに起因しないL2アクセスの別のソースである可能性があります。