CPU内のキャッシュラインを置き換えるためのフローについて考える2.

キャッシュラインを置き換える話その2。

キャッシュラインを置き換える際に、掃き出し用のデータを持っておく必要があるのだが、いくつかのケースでバグに嵌ってしまい再考を余儀なくされている。 ケースとしては、

1. L1Dに書き込みをするためにMissしたライン(物理アドレスAとする)を取りに行く。その際に置き換え対象のライン(物理アドレスBとする)を吐き出す
2. しかしさらに同じラインに対して書き込みが発生し同様にMissする(そのアドレスを物理アドレスCとする)と、同様にラインを取りに行くのだがその時に再度物理アドレスBのラインを吐き出すようになってしまう。

このときの問題は2つあって、

• そもそも物理アドレスBが2回吐き出される
• 最初に要求した物理アドレスAは、物理アドレスCを読み込むときに吐き出すはずなのだが、それができず結局書きつぶされる

これを回避するためにいろいろ考えている。以下はメモ。

---

L1Dのデータ交換はタイミング的に難しいところであるため慎重に設計する必要があります。

ここでは新たに外部から要求する物理アドレスをA、置き換え対象となるL1Dにすでに配置されている物理アドレスをBとします。

パイプライン側からのロードリクエスト L1Dへの物理アドレスAの要求に従い置き換え対象となる物理アドレスB、データ、当該Way番号を取得します。 このWay番号がLRQを経由して新たに書き込まれるWayになります。 ストアバッファからのロードリクエスト ストアバッファはコミット済みのデータを受け取ると以下のように動作します。

• サイクル1. L1Dに対して当該アドレスのリードリクエストを送出する
• サイクル2. L1Dからヒット・ミス情報を取得する。ミスの場合には置き換え対象として掃き出し用の物理アドレス・データ・置き換え対象Wayを取得する
• サイクル3. LRQにデータを渡す。この時にLRQ内のエントリとして同じ掃き出しアドレスを持っている場合、
  • 2回同じL1Dラインのデータが吐き出される可能性がある
  • 当該キャッシュラインに新しいデータがまだ入っておらず、結果として掃き出し用のデータが古い可能性がある

このため、同じ掃き出し対象のデータをLRQ内でで見つけた場合は処理を取りやめ、LRQの解決を待って再度L1Dのデータ取得からやり直す