キャッシュコヒーレンスを管理するバスプロトコルの勉強 (3. それぞれのプロトコルでのキャッシュコヒーレンシのとり方2)

例えば、4CPU + L2キャッシュが存在している状態をまずは考えよう。前回の記事の状態から、さらに、この状態でCPU1が同じキャッシュラインXを読み込もうとした場合はどうなるか。

※以下の説明はChatGPTにかなり頼っているところがある。間違っているところもあるかもしれない...

ACEプロトコル

1. CPU1 発の読み要求 (ARチャネル)
   • CPU1のACEマスタIFが、L2へReadClean あるいは ReadOnceなどのコヒーレントリード要求を出す。
2. インターコネクト or L2 がスヌープ情報を確認
   • 既に CPU0 が Shared 状態で持っていることは、L2のタグやスヌープ・ディレクトリで把握している。
   • 「すでにModifiedを持っているコアがいない」ので大きな書き戻しは不要。
   • ただし、ACE仕様では、同一アドレスを複数コアがSharedで保持する場合でも、スヌープ要求（AC Channel）を送って「実際にModifiedは持っていないのか」と確認する実装もあり得る。CPU0は「Sharedで保持中」と応答（CR Channel）。
3. L2 からデータを送信(R Channel)
   • L2が Clean なラインを保持しているので、そのまま CPU1 へ読み出しデータを返す。
4. CPU1 は Shared 状態を取得
   • これにより、CPU0 と CPU1 は 両方とも Shared で X を保持し、L2も Shared/Clean を維持。

CHI プロトコル

1. CPU1 → L2: REQチャネルでReadShared (または類似コマンド) のリクエストを発行。
2. L2(Home Node) はディレクトリを検索する
   • CPU0 が Shared で保持していることを把握している。
   • Modified を保持しているコアがいないので、書き戻しやInvalidateは不要。
   • 必要であれば、CPU0 へ SNP ChannelでProbe (SharedのままでOKかの確認) を送ることもある。CPU0 は 「Shared状態保持中で特にDirtyなし」という応答(RSP Channel)を返す。
3. L2 → CPU1: DAT Channelでデータを送信
   • L2がCleanのコピーを持っているので、そのデータを CPU1 に転送。
4. RSP Channel: トランザクション完了の応答
   • CPU1 は最終的に読み取り完了を受け取り、Shared状態を獲得。

TileLink プロトコル

1. CPU1 → L2: A Channelで Acquire (読み取り用の権限要求) を送信。
2. L2 (Manager) は状態を確認
   • すでに CPU0 が Shared で持っているが、Modifiedを持っているわけではない
3. L2 → CPU1: D Channelで GrantData を返す
   • L2が持つ Clean なデータを送り、CPU1に Shared 状態を付与 (TileLinkでは “Tip” と呼ぶことが多い)。
4. (Finish) E Channel
   • CPU1 が D Channelを受け取り終わったら、E Channelで完了を通知(実装依存)。
5. CPU1 は Shared/Valid なラインを保持。