問題タブ [mesi]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
multicore - MESIキャッシュコヒーレンスプロトコルはどこでどのように実装されていますか?
MESIプロトコルは、マルチプロセッサシステムでキャッシュコヒーレンスを実装するために使用されていることを知っています。しかし、それがどのように実装されているのかわかりません。これに関するどんな助けも非常にありがたいです。
multithreading - MESI キャッシュ プロトコル
MESI snooping cache coherence protocolについて読んでいましたが、これは現代のマルチコア x86 プロセッサで使用されているプロトコルだと思います (間違っていたら訂正してください)。今、その記事は一箇所でこれを言っています。
Modified 状態のラインを保持するキャッシュは、対応するメイン メモリ ロケーションの (システム内の他のすべてのキャッシュからの) 試行されたすべての読み取りをスヌープ (インターセプト) し、保持しているデータを挿入する必要があります。これは通常、読み取りを強制的にバックオフ (つまり、後で再試行) してから、データをメイン メモリに書き込み、キャッシュ ラインを共有状態に変更することによって行われます。
今私が理解していないのは、データをメインメモリに書き込む必要がある理由です。キャッシュ コヒーレンスは、メモリに移動せずにキャッシュ内のコンテンツを同期したままにできますか (もちろん、キャッシュ ラインが完全に削除されない限り)。つまり、一方のコアが常に読み取り、もう一方のコアが常に書き込みを行っている場合、データをキャッシュ メモリに保持し、キャッシュ内のデータを更新し続けてみませんか。メインメモリへの書き戻しのパフォーマンスが発生するのはなぜですか?
つまり、コアがデータを読み取り、書き込みコアのキャッシュから直接読み取り、それに応じてキャッシュを変更することはできませんか?
caching - 状態遷移を理解する MESI プロトコル
以下に示すイリノイ MESI プロトコルの状態遷移図では、状態 S から状態 I に遷移するときに Flush' 信号があり、BusRdX 信号を観察すると、状態 E から状態 I に移行するときに Flush 信号があるのはなぜですか。これらの状態のプロセッサのキャッシュ コンテンツは、メイン メモリ内のコンテンツと同じではありませんか? もしそうなら、これらのキャッシュが私にデータをフラッシュするように指示するポイントは何でしょうか? また、フラッシュとフラッシュの違いは正確には何ですか?Flush' では、データが 1 つのキャッシュによって転送されて交換されるだけですか?
遷移図:
caching - mesi キャッシュ コヒーレンス プロトコルは、2 つの論理コアを持つシングル プロセッサに適用できますか?
Intel Atom プロセッサ (純正 Intel(R) CPU) を使用しています。cat/proc/cpuinfo を実行しました。2 つのプロセッサが表示されていますが、物理 ID とコア ID については 0 が表示されています。並べ替え -u | wc -l を実行して、CPU コアの数を見つけます。1 と表示されています。これはどういう意味ですか? 物理コアが 1 つと論理コアが 2 つしかありませんか? この場合、メシ キャッシュ コヒーレンス プロトコルは適用できますか?
caching - キャッシュ整合性における MESI プロトコル
MESI プロトコルについて質問があります。
(1) MESI キャッシュ コヒーレンス プロトコルを実装するユニプロセッサ システムで実行される次のコード フラグメントを考えてみましょう。
I1: ロード $s1, [A] I2: ロード $s2, [B] I3: 追加 $s1, $s2, $s3 I4: ストア $s3, [C] I5: サブ $s3, 1, $s4 I6: $s3 を保存、[A]
ライトスルー キャッシュ ポリシーを仮定します。メモリ ブロック A、B、および C が (必要に応じて) 1 つのプロセッサ上の 2 つの異なるキャッシュ ブロック (最初は空) に読み込まれる場合、次の表を完成させて、それぞれの後に A、B、C を含むブロックのキャッシュ状態を特定します。命令が実行されます。
それに対する私の答えは次のとおりです。
(2) 次の RTL では
ライトスルー キャッシュ ポリシーを仮定します。メモリ ブロック 4 と 6 が単一のプロセッサの 2 つの異なるキャッシュ ブロック (最初は空) にロードされている場合
私の答えは
私の答えは正しいですか?事前にどうもありがとうございました。
multithreading - MESIプロトコルとLRU戦略
MESI プロトコルと、キャッシュの一貫性を維持するためのそのアプリケーションに関するかなりの文献を読みましたが、よくわからない詳細が 2 つあります。
複数のキャッシュの同期を維持するために MESI プロトコルを使用し、キャッシュ ラインに LRU 戦略を適用する場合、ラインは読み取りアクセスによってのみキャッシュに保持されますか、それとも書き込みアクセスによっても保持されますか?
また、キャッシュ A の共有ラインでのキャッシュ ヒットは、キャッシュ B の LRU オーダーでそのラインを表示しませんか?
multithreading - MESIプロトコルのパフォーマンスコストは?
MESI (Modified, Exclusive, Shared, Invalid) プロトコルは、CPU キャッシュが通信し、すべてがキャッシュ ラインの最新の値を使用していることを確認するために使用されます。1 つの CPU がキャッシュ ラインの値を変更すると、このキャッシュ ラインにサブスクライブしている他のすべての CPU は、キャッシュ ラインへの変更に関するアラートを受け続けます。
ただし、MESI に関して読んだすべての文献で、プロトコルの通信中にパフォーマンス コストが発生するかどうかはわかりませんでした。このコストは、x86LOCK
プレフィックスのコストの一部にすぎませんか? LOCK
x86プレフィックスが使用できない場合でも、MESIを使用できると確信していますか?
NB Intel は実際には MESIF プロトコルを使用しています。ここで、F は追加の「転送」状態です。
cpu - MESI によって誘導されたメッセージに対する書き込みバッファーの反応
次のような状況があるとします。書き込みバッファを備えた 2 つの CPU で、キャッシュ コヒーレンス プロトコルとして MESI が使用されています。そして、CPU 間に 1 つの共有キャッシュ ラインがあります。
CPU1 キャッシュ:|I|I|S|I|I|
CPU2 キャッシュ:|I|I|S|I|I|
ここで、CPU1 は共有回線を変更することを決定します。変更レコードを書き込みバッファに置き、無効化メッセージを CPU2 に送信します。CPU2 はそれを受信し、確認応答を送信します。
CPU1 キャッシュ: |I|I|S|I|I|
、CPU1 書き込みバッファ:change for the 3rd cache line
CPU2 キャッシュ:|I|I|I|I|I|
CPU1 が確認応答を受信すると、書き込みバッファをフラッシュしてキャッシュ ラインの状態を M(modified) に変更する必要がないというのは正しいですか? そうでない場合は、さらに先に進みましょう。
ここで、CPU2 がこのキャッシュ ラインを再度読み取りたいとします。スヌーピング CPU1 はこの読み取り要求をインターセプトする必要がありflush buffer->flush cache line->send the last value of the cache line to CPU2
ますか? または、それを無視して、CPU2 が RAM (まだ変更されていない) に要求することによって古い値を保持している可能性がありますか?