web-dev-qa-db-ja.com

物理アドレス指定または仮想アドレス指定は、L1、L2、およびL3でキャッシュするためにプロセッサx86 / x86_64で使用されますか?

L1、L2、およびL3(LLC)でのキャッシュのためにプロセッサx86/x86_64で使用されるアドレス指定-物理または仮想(PT/PTEおよび [〜#〜] tlb [〜#〜] )そしてどういうわけか PAT(ページ属性テーブル) はそれに影響しますか?

この場合、ドライバー(カーネルスペース)とアプリケーション(ユーザースペース)に違いはありますか?


簡単な答え-Intelは仮想的にインデックス付けされ、物理的にタグ付けされた(VIPT)L1キャッシュを使用します: スレッド間のデータ交換に使用されるものはHTを備えた1つのコア?

  • L1-仮想アドレス指定(8-way定義用のキャッシュSetが必要です低12 bitsこれはvirtとphysで同じです)
  • L2-物理アドレス指定(Virt-2-PhysのTLBへのアクセスが必要)
  • L3-物理アドレス指定(Virt-2-PhysのTLBへのアクセスが必要)
28
Alex

あなたの質問への答えは-それは異なります。これは厳密にはCPU設計の決定であり、パフォーマンスと複雑さの間のトレードオフのバランスを取ります。

最近のIntelCoreプロセッサを例にとってみましょう-それらは物理的にタグ付けされ、仮想的にインデックスが付けられています(少なくとも http://www.realworldtech.com/sandy-bridge/7/ による)。これは、ラインが存在するかどうかを判断するために、キャッシュが純粋な物理アドレス空間でのみルックアップを完了できることを意味します。ただし、L1は32k、8ウェイアソシアティブであるため、64セットを使用することを意味します。したがって、正しいセットを見つけるために必要なのは、アドレスビット6〜11だけです。たまたま、この範囲では仮想アドレスと物理アドレスが同じであるため、キャッシュセットの読み取りと並行してDTLBを検索できます。これは既知のトリックです( http://en.wikipedia.orgを参照)。/wiki/CPU_cache 良い説明のために)。

理論的には、仮想インデックス+仮想タグ付きキャッシュを構築できます。これにより、アドレス変換(TLBルックアップ、およびTLBミスの場合のページウォーク)を実行する必要がなくなります。ただし、これにより、特にメモリエイリアシング(2つの仮想アドレスが同じ物理アドレスにマップされる場合)で多くの問題が発生します。

Core1がそのような完全仮想キャッシュに仮想アドレスAキャッシュを持っているとしましょう(これはphysアドレスCにマップされますが、このチェックはまだ行っていません)。 core2は、同じphysアドレスCにマップする仮想アドレスBに書き込みます。これは、core1のその行を無効にして、データのマージとコヒーレンシ管理を管理するメカニズム(通常は「スヌープ」、Jim Goodmanによって造られた用語)が必要であることを意味します。必要に応じて。ただし、core1は仮想アドレスBを認識せず、物理アドレスCを仮想キャッシュに格納しないため、そのスヌープに応答できません。したがって、問題があることがわかります。これは、厳密なx86システムに主に関連していますが、他のアーキテクチャはより緩く、そのようなキャッシュのより簡単な管理を可能にする場合があります。

他の質問に関して-私が考えることができるPATとの実際の関係はありません、キャッシュはすでに設計されており、異なるメモリタイプに対して変更することはできません。他の質問に対する同じ答え-HWは、ほとんどの場合、ユーザー/カーネルモードの区別の下にあります(セキュリティチェックを提供するメカニズム、ほとんどの場合、さまざまなリングを除く)。

36
Leeor