ページテーブルウォークはキャッシュされますか？

ハードウェアTLB管理を備えたマイクロプロセッサ（Intel x86-64など）でTLBミスが発生し、プロセッサがページテーブルを歩いている場合、これらの（オフチップ）メモリアクセスはキャッシュ階層（L1、L2など）を通過します。 ）？

はい、Intel x86-64プロセッサでは、TLBミスが発生し、プロセッサがページテーブルを歩いているときに、それらのオフチップメモリ​​アクセスがキャッシュ階層を通過します。

私はまだいくつかの詳細について少しあいまいですが、他の答えがそれらを埋めることを願っています-ページウォークを非常に詳細に説明しているIntelまたはAMDのマニュアルはありませんか？私の理解は：

• アドレスレジスタの仮想アドレスは、最初に高速TLBに渡されて物理アドレスに変換されます。PCのアドレスはL1 ITLBに渡され、他のレジスタのアドレスはL1 DTLBに渡されます。 。
• 最初のルックアップが失敗した場合、別のレベルのより低速で大きなTLBが試行されます。（このL2 TLBもITLBとDTLBに分割されていますか、それとも統合TLBキャッシュですか？さらにTLBレベルがあります-L3？L4？）
• TLBルックアップが完全に失敗し、x86およびx86-64 VHPTウォーカーが無効になっている場合、CPUはTLBミスフォールトを通知し、OSカーネルによってインターセプトされます。私の理解では、実質的にすべての非x86 CPUは同じことを行い、TLBミスを完全にソフトウェアで処理します。有効にした場合、x86およびx86-64プロセッサには、次のいくつかの手順を処理するハードウェア支援VHPTテーブルウォーカーがあります。（x86およびx86-64チップには、VHPTを完全に無効にするビットが1つありますか、それとも一部のアドレス範囲でVHPTを有効にし、他のアドレス範囲でVHPTを無効にできるビットがありますか？それらのビットはどこにありますか？）
• TLBルックアップが完全に失敗した場合、元の（おそらくユーザーモードの）仮想アドレスV1は、V1の物理ページ番号を保持するページテーブルエントリPTEの仮想アドレスV2に変換されます。
• V2は再び仮想アドレスであるため、CPUは通常の仮想アドレスから物理アドレスへの変換を行いますが、L1をスキップしてL2に進むことを除きます。
• ハードウェアは、（仮想的にインデックス付けされた）L2キャッシュからそのPTEをフェッチするのと並行して、TLBで仮想アドレスV2を検索します。
• V2は命令のアドレスではないため、L1命令キャッシュを経由しません。また、V2は通常のユーザーデータのアドレスではないため、L1データキャッシュを通過しません。V2は、最初にL2統合キャッシュ（統合命令+データ+ PTEキャッシュ）に供給されます。「キャッシュ階層の例」を参照してください。
• L2キャッシュ（またはL3またはその他の仮想インデックス付きキャッシュ）にPTEが含まれている場合、VHPTはキャッシュメモリからPTEをフェッチし、TLBにV1のPTEをインストールし、そのPTEの物理アドレスを使用して元の仮想アドレスV1を物理RAMアドレスに格納し、最終的にOSの支援なしでそのデータまたは命令を完全にハードウェアでフェッチします。
• 仮想インデックス付きキャッシュのすべてのレベルが失敗したが、V2でこの2番目のTLBルックアップが成功した場合、VHPTは物理インデックス付きキャッシュまたはメインメモリからPTEをフェッチし、TLBにV1のPTEをインストールし、その中の物理アドレスPTEを使用して、元の仮想アドレスV1を物理RAMアドレスに変換し、最終的にOSの支援なしでそのデータまたは命令を完全にハードウェアでフェッチします。
• この2番目のTLBルックアップが失敗すると、ハードウェアVHPTウォーカーはVHPT TRANSLATION FAULTをあきらめます。
• VHPT TRANSLATION FAULTが発生すると、CPUはOSにトラップします。OSは何がうまくいかなかったかを把握し、修正する必要があります。
• （a）おそらく、V2を含むページは現在ディスクにスワップアウトされているため、OSはそれをRAMに読み込み、失敗した命令を再開します。
• （b）バグのあるプログラムが無効な場所の読み取りまたは書き込みまたは実行を試みており、OSがプロセスを終了している可能性があります。
• （c）OSライターがこのメカニズムを使用してさまざまな種類のアクセスをトラップするために行うその他のさまざまなトリック-ディスクにスワップアウトされる可能性のあるV1を含むページをロードします。新しいプログラムのデバッグに使用されるさまざまなトラップ。直接サポートしていないCPUで「W ^ X」をシミュレートする。コピーオンライトをサポートするため。等

Thomas W. Barr、Alan L. Cox、Scott Rixnerの2ページ目の図。 「翻訳キャッシュ：スキップして、歩いてはいけません（ページテーブル）」 は、「MMUキャッシュによって保存されたエントリ」と「L2データキャッシュによって保存されたエントリ」の間に線を引きます。（これは、新しいCPUを設計する人々にとって有用な論文になる可能性があります。これは、「電子設計」のトピックに完全に当てはまります）。

ステファン・エラニアンとデビッド・モスバーガー。 「IA-64 Linuxカーネルの仮想メモリ」 およびUlrich Drepper。 「すべてのプログラマは、メモリについて何を知っている必要があります」 と、おそらくスタックオーバーフロー- （これはEDのためのビットオフトピックであるIA-64ページテーブルを扱うことのオペレーティングシステムを書く人々のために有用かもしれ紙「operating- system」タグ、「osdev」タグ、またはOSDev.org wiki がそのトピックに適しています。

Intelの533ページの表A-10。 「 Intel®64 およびIA-32アーキテクチャソフトウェア開発者マニュアル」「PAGE_WALKS.CYCLES ...は、ページウォークのほとんどがキャッシュによって満たされるか、L2キャッシュミスを引き起こすかを示唆できます。」

これは、電子機器のスタック交換ではなく、コンピューターアーキテクチャのスタック交換に属していることに同意する傾向がありますが、これはここにあるためです。

@davidcaryは正しいです。

いくつかの歴史：

Intel x86ページテーブルウォークは、P5（別名Pentium）までキャッシュされませんでした。より正確には、ページテーブルウォークのメモリアクセスはキャッシュされず、キャッシュをバイパスしました。それまでのほとんどのマシンはライトスルーであったため、キャッシュと一致する値を受け取りました。しかし、彼らはキャッシュをスヌープしませんでした。

P6、別名Pentium Pro、およびAFAIK以降のすべてのプロセッサのページテーブルウォークは、キャッシュにアクセスし、キャッシュから取得した値を使用できました。したがって、ライトバックキャッシュを使用していました。（もちろん、MTRRで定義されたキャッシュ不可メモリにページテーブルを配置することもできます。しかし、OSのデバッグには役立ちますが、これは大きなパフォーマンスの低下になります。）

ちなみに、この「ページテーブルウォークメモリアクセスがデータキャッシュにアクセスする可能性がある」は、「ページテーブルエントリがTLB Ttranslation Lookasideバッファに格納（キャッシュ）される」とは別です。一部のマシンでは、TLBは「トランスレーションキャッシュ」と呼ばれます。

別の関連する問題は、ページテーブルの内部ノードが、さらに多くのTLBのようなデータ構造、たとえばPDEキャッシュにキャッシュされる可能性があることです。

1つの重要な違い：データキャッシュは一貫性があり、スヌープされます。ただし、TLBおよびPDEキャッシュはスヌープされません。つまり、一貫性がありません。結論として、ページテーブルは非コヒーレントTLBやPDEキャッシュなどにキャッシュされる可能性があるため、ページテーブルエントリがそうである可能性がある場合、ソフトウェアは個々のエントリまたはバルクグループ（TLB全体など）を明示的にフラッシュする必要がありますキャッシュが変更されます。少なくとも「危険」な方法で変更された場合、RW-> R-> Iから変更された場合、またはアドレスを変更された場合。

これは、新しいタイプの非コヒーレントTLBのようなキャッシングが追加されるたびに、これが行われていないという暗黙の仮定があったため、一部のOSが壊れたと言ってもいいと思います。