Firefly (キャッシュコヒーレンスプロトコル)

Firefly キャッシュ コヒーレンスプロトコルは、 DEC Systems Research Centerによって開発された、 DEC Fireflyマルチプロセッサ ワークステーションで使用されるスキーマです。このプロトコルは、3 ステートの書き込み更新キャッシュ コヒーレンス プロトコルです。Dragonプロトコルとは異なり、Firefly プロトコルは、書き込み更新バス遷移時にメイン メモリとローカル キャッシュを更新します。したがって、Dragon プロトコルの場合に存在する共有クリーン状態と共有変更状態は、Firefly プロトコルの場合は区別されません。

このプロトコルでは、各ブロックに次の状態を割り当てることができます。

• Valid-Exclusive(V) : キャッシュ ブロックは有効でクリーンであり、1 つのキャッシュにのみ存在します。
• 共有(S) : キャッシュ ブロックは有効でクリーンであり、複数のキャッシュに存在する可能性があります。
• ダーティ (D) : ブロックはメモリの唯一のコピーであり、ダーティです。つまり、メモリから取得されてからその値が変更されています。これは、ブロックがキャッシュ内で置き換えられたときにライトバックを生成する唯一の状態です。

これらの状態は、MESI プロトコルのExclusive、Shared、およびModified状態に対応します。このプロトコルは、バス トランザクションを介して無効化をトリガーすることはないため、Invalid状態はここにはリストされていません。キャッシュ ラインが無効になるのは、エビクションの場合のみです。

プロセッサ側のリクエストまたは CPU リクエストは、プロセッサが自身のキャッシュに対して行うアクセスです。これらは次の 4 種類のリクエストに分類できます。

1. PrRdMiss : キャッシュ内に存在しないキャッシュ ブロックを読み取るためのプロセッサ側の要求。
2. PrRdHit : すでにキャッシュ内に存在するキャッシュ ブロックを読み取るためのプロセッサ側の要求。
3. PrWtHit : すでにキャッシュ内に存在するキャッシュ ブロックへの書き込みをプロセッサ側が要求します。
4. PrWtMiss : キャッシュ内に存在しないキャッシュ ブロックへの書き込みをプロセッサ側が要求しました。

バス側リクエストは、キャッシュの一貫性を維持するためのプロセッサ側リクエストに応答して生成されるリクエストです。これらはキャッシュとメモリのスヌーパーによってスヌープされ、適切なアクションが実行されます。これらは、Firefly プロトコルでは次の 2 つのタイプに分類されます。

1. BusRd : 別のプロセッサによってキャッシュ ブロックへの読み取り要求が行われ、そのプロセッサにはデータがないことを示す要求。

2. BusWr/BusUpdt : 別のプロセッサによってキャッシュ ブロックへの書き込み要求が行われ、他のすべてのキャッシュがブロックのコピーを更新する必要があることを示す要求。

どの遷移を行う必要があるかを識別するために、プロトコルはCopiesExistという特別なバス ラインを使用して共有を検出します。他のすべてのキャッシュはすべてのメモリ操作をスヌープし、「スヌープ ヒット」を検出した場合、つまり独自のキャッシュにデータのコピーがある場合にCopiesExist(C)を発生させます。

どこからも見えないところから状態に向かう矢印は、新しくロードされたブロックを表します。

プロセッサがブロックを読み取りミスし、他のキャッシュにブロックのコピーがない場合、CopiesExist (C) 行がチェックされ、C が LOW であれば、ブロックはキャッシュに配置され、状態はValidに設定されます。一部のキャッシュにすでにコピーがある場合 (C が HIGH の場合)、ブロックはShared状態でキャッシュに配置されます。

ブロックへの書き込みミスが発生した場合、どのキャッシュにもブロックのコピーがない場合 (C が LOW)、ブロックはDirty状態でキャッシュに配置されます。一部のキャッシュにブロックのコピーがすでに存在する場合 (C が HIGH)、ブロックはShared状態でキャッシュに配置され、変更がメモリに反映されます。

ブロックがすでに有効状態でキャッシュされている場合、プロセッサの書き込みヒットにより、他のキャッシュにデータのコピーがないため、 状態がダーティ状態に変更されます。この書き込みはメモリに書き込まれません。

ブロックがダーティ状態でキャッシュされ、プロセッサ書き込みヒットが発生した場合、状態はダーティ状態のままになります。

ブロックが共有状態にあり、プロセッサ書き込みヒットがあり、一部のキャッシュにすでにコピーがある場合 (C)、ブロックは共有状態のままになります。どのキャッシュにもブロックのコピーがない場合 (!C)、ブロックはキャッシュに存在する唯一の「有効な」コピーであるため、 有効状態で書き込まれます。

CPU 読み取りヒットがあった場合、ブロックは Dragon プロトコルの場合と同様に、現在の状態のままになります。

ブロックが共有状態にあり、BusRd または BusWr 要求がある場合、ブロックは共有状態のままになります。

ブロックがダーティ状態にあり、別のプロセッサがそれを読み取りまたは書き込み、別のプロセッサからの要求があった場合、ブロックは共有状態に移行し、変更がメインメモリに反映されます。

ブロックが有効状態にあり、別のプロセッサがそれを読み取ると、共有状態に移行します。別のプロセッサの書き込み要求がスヌープされると、ブロックが更新され、共有状態になったため、共有状態に移行します。

MESI とは異なり、Firefly 更新プロトコルでは、プロセッサ (PrWr) による書き込み要求時に他のすべてのコピーを直接更新することによって書き込みの伝播が保証されます。

1. データの更新されたコピーがキャッシュ内に存在するため、書き込み - 無効化ポリシーよりも一貫性のミスが少なくなります。

2. 無効化プロトコルでは、バス上で信号/コマンドを送信するだけで、他のプロセッサでスヌープされ、それらのプロセッサのデータのコピーが無効化されるため、無効化プロトコルよりも高いバス帯域幅が必要になります。対照的に、更新プロトコルでは、メモリやその他のキャッシュがデータをスヌープして更新できるように、新しいデータ値を BusUpdate 信号とともに送信する必要があります。

3. 書き込みのたびにデータを更新すると、不要になったデータがキャッシュ内に残り、一部の「有用な」データが削除される可能性があります。

• DEC ファイアフライ
• DEC システム研究センター
• キャッシュの一貫性
• MSI プロトコル
• MESIプロトコル
• ドラゴンプロトコル

• Hashemi, B. (2011-05-01)。「共有メモリ マルチプロセッサ システムにおける更新戦略による Snoopy キャッシュ コヒーレンス プロトコルのシミュレーションと評価」。2011 IEEE 第 9 回国際並列分散処理シンポジウムおよびアプリケーション ワークショップ。pp. 256–259。doi :10.1109/ ISPAW.2011.68。ISBN 978-1-4577-0524-3.S2CID 2093087  。
• Eggers, SJ; Katz, RH (1988-01-01)。並列プログラムにおける共有の特性と、その一貫性プロトコル評価への応用。ISCA '88。第 16 巻。米国カリフォルニア州ロサンゼルスアラミトス: IEEE Computer Society Press。pp. 373–382。doi : 10.1145 /633625.52442。ISBN 978-0818608612。 {{cite book}}:|journal=無視されました (ヘルプ)
• Archibald, James; Baer,​​ Jean-Loup (1986-09-01). 「キャッシュ コヒーレンス プロトコル: マルチプロセッサ シミュレーション モデルを使用した評価」. ACM Trans. Comput. Syst . 4 (4): 273–298. doi : 10.1145/6513.6514 . ISSN  0734-2071. S2CID  713808.