私の知る限り、CPUのメモリアクセスには、CPUキャッシュとMMUが関係しています。 CPUはキャッシュ内のターゲットを見つけようとします。キャッシュミスが発生すると、CPUはMMUに変わります。 MMUによるアクセス中に、対応するページテーブルエントリのアクセス/ダーティビットがハードウェアによって設定されます。メモリにアクセスするとき、キャッシュヒットの状況下でページテーブルのアクセス/ダーティビットを設定しますか？
私が知っている限り、ほとんどのCPU設計では、キャッシュミスがないかぎりMMUがトリガーされません。ここで私の問題は、ページテーブルエントリのアクセス/ダーティビットがキャッシュヒット？それともアーキテクチャに関連している？
高速アクセスのために、ほとんどのキャッシュは仮想的にインデックスされ、物理的にタグ付けされています。したがって、CPUは仮想アドレスを発行し、アドレスのインデックスビットを使用してエントリを特定します。この間、物理アドレスを取得するためにアドレスがTLBに送信されます。キャッシュにエントリが配置されるまでに、TLBはTAG比較に使用された物理アドレスを返します。 2つのことは起こり得ません。
は、ページ・テーブル・エントリ（PTE）にアクセスする必要があるのを持っていませんでした
2の場合、TLBが有効なマッピングを返した場合、それをフェッチするだけです。 TLB alssにミス（1と2）がある場合は、PTEから物理アドレスを取得してデータを取得する必要があります。
あなたの質問に答えるには、HITの場合、PTEはそれについてすべて知る必要はありません。
ページが最初にアクセスされなかった場合、通常はキャッシュヒットができないため、質問は関係ありません。 （編集：それを考えると、ページエイリアシングのいくつかの奇妙なケースでは可能かもしれませんが、汚れたビットについて同じ答えがそこに適用されます）
クリーンなページからキャッシュされた行を持つことは可能です以前に書かれた）。通常、データにアクセスする前にデータを初期化する必要があるため、ページを以前にスワップアウトしてからページマップに再インストールすることはほとんどありません（OSに依存しますが、可能です）。
この場合、行はキャッシュされています（排他的に言えば）、その行に書き込みます。 CPUはキャッシュとTLBに同時にアクセスし、キャッシュ内の行をルックアップしながら、システムが物理的にマップされていると仮定してTLBアクセスを行って完全な仮想タグを検証しようとします。 TLBプロセスは、実際のページマップからのメモリにTLBエントリをインストールするために、TLBヒットまたはミスの後にページウォークのいずれかを完了することができる。
キャッシュアクセスは、TLBアクセス（および必要に応じてページウォーク）が完了するまで完了できません。その時点で、アクセス/ダーティービットの値がわかります。 ダーティビットが設定されていないページに書き込み（またはアクセスビットのないページにアクセス）しようとすると、ページフォルトが発生し、OSがページテーブルのページを更新します。 OSはこの時点でさまざまな最適化を行うことを選択することができますが、最終的にこれらのビットを修正する結果になります。
ありがとうございます、私はOSがページテーブル内のアクセスされたビットを時々クリアすると思います（たとえば、ページ再利用中）、キャッシュされたページにはアクセスされていないビットが設定されていない可能性があります。私はあなたの答えを完全に理解しているかどうかはわかりませんが、汚れた/アクセスしていないビットを設定しないでページにアクセスすると、ページフォルトが発生するでしょうか？ –
はい。コードがそのようなページにアクセスすると、エラーが発生します。一方、OSが何らかの形で（おそらく外部プロセスやカーネル内で）ページマップを変更した場合、TLBにキャッシュされたコピーを強制的に更新する必要があるため、通常はTLBのシャットダウンを取得します – Leeor
Thx、キャッシュヒットとTLBヒットの両方が発生した場合、PTEのビットは設定されません。 –
私の知る限り、はい。 –