4

友達オペレーティングシステムによるキャッシュ汚染がアプリケーションのパフォーマンスに与える影響を調べたいと思います。
このために、私は小さなカスタムベンチマークプログラムを作成しました。

1. malloc an array of size = l1 data cache-size
2. repeat ... sweep this array from start to end (hit-rate = 1.0)
3. *** perform a system call that thrashes l1 data cache ***
4. sweep the array once again (expected hit-rate = ~0.7 ---> 1.0)

アルゴリズムのステップ2は、配列全体を繰り返し読み取ります。うまくいけば、配列はキャッシュに残り、ヒット率は1になります。

システムコールを実行した後、もう一度キャッシュを読み取ろうとします。しかし、OSがユーザーに属するいくつかのキャッシュラインを削除したと思います。

ご覧のとおり、プログラムはシステムコールに依存して、l1データキャッシュから多くのユーザーデータラインを削除します。どうすればこれを達成できますか？

システムコールはファイル関連またはストリーム関連のいずれかである必要があると思います。

4

2 に答える 2

1

L1キャッシュへの影響は、システムコールごとに異なります。1つの方法は、いくつかの異なるシステムコールをループして、それぞれの影響を測定することです（たとえばwrite()、バッファのサイズを変更できるI / O関連の呼び出しを含むため、キャッシュへの影響の可能性があります）。

カーネル空間への切り替えを必要としないため、vsyscalls（例）として実装されたシステムコールは避けたいと思うでしょう。gettimeofday()[1、2]を参照してください。

L1dへの影響を分離したいようですので、注意が必要なもう1つの点があります。ステップ2では、配列をループした後、L1iキャッシュにデータが入力されます。システムコールが完了した後、L1dとL1iの両方が汚染されている可能性があるため、i-cacheミスのパフォーマンスへの影響も確認できる場合があります。

アーキテクチャによっては、よりきめ細かい測定を行うために、ハードウェアパフォーマンスカウンターを利用できる場合があります。

于 2012-04-23T23:17:08.677 に答える
0

私はヘネシーとパターソン-スレッドレベルの並列処理-OSとマルチプログラミングワークロードを読んでいました。アクティビティでL1キャッシュが高いことが示されている例は、いくつかのベンチマークコードのコンパイルです。おそらく、コンパイル可能なコードをいくつか作成し、ステップ3でそのコンパイルを生成して、L1キャッシュを変更することができます。しかし、はい、L1iも変更されます。

于 2019-10-08T09:37:22.223 に答える