問題タブ [cpu-cache]

i386 Linux で。できれば c/(c/posix std libs)/proc にあることが望ましいです。そうでない場合、これを行うことができるアセンブリまたはサードパーティのライブラリはありますか?

編集：カーネルモジュールがキャッシュラインまたはプロセッサ全体をクリアするかどうかのテストを開発しようとしています（wbinvd（）を使用）。プログラムはルートとして実行されますが、可能であればユーザー空間にとどまりたいです。

したがって、Linux カーネルで基本的な L1 および L2 キャッシュ関連ルーチンをプログラミングした後 ( arch/arm/mm/cache-X.S)、たとえば ARM11 プロセッサに固有の場合、無効化やフラッシュが適切に行われるようにキャッシュが適切に機能しているかどうかをテストするために使用できるテスト ユーティリティ/プログラムはありますか? 独自のプログラムに頼るのではなく、どうすればそれを保証できるか。

特別なメモリ ブロックは、DMA タスクによって定期的に更新されます。別のタスクがこのブロック内のデータを頻繁に参照しようとした場合、L1 データ キャッシュのパリティ チェックに関する MCE (Machine Check Exception) が発生します。このメモリ ブロックの L1 データ キャッシュを完全に無効にすることはできますか? または DMA 更新後にのみ無効にすることはできますか?

libogc には次のような興味深い API があります。

私は ASM にも PowerPC 上の ASM にも精通していません。人々はこの操作に関するリンクや説明を推奨しますか?

.NETの世界でのCPUキャッシュのパフォーマンスについて学ぼうとしています。具体的には、プロセッサキャッシュ効果に関するIgorOstovskyの記事を読んでいます。

私は彼の記事の最初の3つの例を調べ、彼とは大きく異なる結果を記録しました。私のマシンのパフォーマンスは、彼の記事に示されているものとほぼ正反対の結果を示しているので、私は何か間違ったことをしているに違いないと思います。キャッシュミスによる大きな影響は期待できません。

私は何が間違っているのですか？（不正なコード、コンパイラ設定など）

これが私のマシンでのパフォーマンス結果です。

それが役に立ったら、私のマシンのプロセッサはIntelCorei7-2630QMです。これが私のプロセッサのキャッシュに関する情報です：

x64リリースモードでコンパイルしました。

以下は私のソースコードです：

私のコンピュータ アーキテクチャの授業で、教授は次のような質問を私たちに投げかけました。

なぜ制限があるのか​​、それが何であるかはわかりません。Googleで検索した後、これに対する正確な答えが見つからないようです。誰かが制限がある理由とそれらの制限が何であるかを説明できますか、または質問に答えるのに役立つ方向性を教えてくれますか?

今週の私の課題についてこの質問がありますが、キャッシュを無効にする方法や、アセンブリプログラムでキャッシュを表示する方法がわかりません。誰かが私を正しい方向に向けることができますか？

アセンブリプログラムの例を使用して、2つの異なるキャッシュ（連想および直接マッピング）を無効にする方法を示します。これが発生する理由と修正方法を説明してください。キャッシュを無効にするために使用される同じプログラムは同じですか？

注：これは宿題です。質問に答えるだけでなく、資料を理解するのに役立ちません。

Linux で WBINV 命令を使用して、プロセッサの L1 キャッシュをクリアしようとしています。

次のプログラムはコンパイルされますが、実行しようとするとセグメンテーション違反が発生します。

int main() {asm ("wbinvd"); return 1;}

gcc 4.4.3 を使用しており、x86 ボックスで Linux カーネル 2.6.32-33 を実行しています。

プロセッサー情報: Intel(R) Core(TM)2 Duo CPU T5270 @ 1.40GHz

次のようにプログラムを作成しました。

$ gcc

$ ./a.out

セグメンテーション違反

誰かが私が間違っていることを教えてもらえますか? これを実行するにはどうすればよいですか？

PS: いくつかのパフォーマンス テストを実行していますが、プロセッサ キャッシュの以前の内容が結果に影響しないことを確認したいと考えています。

私はチェスの動きのジェネレーターを実行しています。「while/forloops」を多くの「ifステートメント」に置き換える機会があります。これらの〜3000行を追加すると、理論どおりにパフォーマンスが向上するのか、それともアルゴリズムも向上するのか疑問に思いました。 CPUキャッシュに保存される大きな

キャッシュサイズによって異なりますが（AMD Phenom 8650 Triple Core 2.3を入手しました）、実際にはIDEAを持っていません。

例から始めましょう。

4 ソケットのシステムがあり、各ソケットに 4 つのコアがあり、各ソケットに 2GB RAM ccNUMA (キャッシュ コヒーレント不均一メモリ アクセス) タイプのメモリがあるとします。

実行中の 4 つのプロセスが各ソケット上にあり、そのすべてに SHM で示される P2 の RAM に割り当てられた共有メモリ領域があるとします。これは、そのリージョンへのロード/ストアによって、P2 のディレクトリへのルックアップが発生することを意味しますよね? もしそうなら... そのルックアップが起こるとき、それはレイテンシの観点からRAMにアクセスすることと同等ですか? このディレクトリは物理的にどこにありますか? （下記参照）

より具体的な例: P2 が SHM で LOAD を実行し、そのデータがタグ「(O)wner」で P2 の L3 キャッシュに取り込まれるとします。さらに、P4 が同じ SHM で LOAD を実行するとします。これにより、P4 は P2 のディレクトリを検索し、データは P2 によって所有されているとタグ付けされているため、私の質問は次のとおりです。

P4 は P2 の RAM から SHM を取得しますか? それとも常に P2 の L3 キャッシュからデータを取得しますか?

常に L3 キャッシュからデータを取得する場合、P2 の RAM から直接データを取得する方が高速ではないでしょうか? すでに P2 のディレクトリを検索する必要があるためですか? そして私の理解では、ディレクトリは文字通り RAM の上にあるということです。

ここで何が起こっているのかをひどく誤解している場合は申し訳ありませんが、誰かがこれを明確にするのを手伝ってくれることを願っています.

また、そのようなディレクトリ検索の速度に関するデータはありますか? データ取得に関して、そのようなルックアップの平均レイテンシに関するドキュメントはありますか? L3 読み取りヒット、読み取りミス、ディレクトリ ルックアップのサイクル数は? 等