私は C++ で書いたプログラムを持っています。Linux では、プロセスに一定量のメモリが割り当てられます。一部はスタック、一部はヒープ、一部はテキスト、一部はBSSです。
次のことは正しいですか。
プロセスのヒープ コンポーネントに割り当てられるメモリの量が増えると、変換ルックアサイド バッファ ミスが発生する可能性が高くなりますか?
一般的に言って、アプリケーション プロセスが消費するメモリが多いほど、TLB ミスの可能性が高くなりますか?
2 に答える
2
割り当てられたメモリの量と TLB のミス率の間に直接的な関係はないと思います。私の知る限り、プログラムの局所性が良好である限り、TLB ミスは低く抑えられます。
高い TLB ミスにつながるいくつかの理由があります。2.プログラムの局所性が低い。3.コード内のサイクルで配列要素にアクセスする非効率的な方法。
于 2014-01-10T02:34:08.257 に答える
1
プログラムは通常、まったく異なるメモリと実行特性を示すフェーズに分割されます。コードは、ある時点で巨大なメモリ チャンクを割り当て、その後、他の無関係な計算を実行しなくなる場合があります。その場合、TLB (基本的にはアドレス変換用のキャッシュにすぎません) は、未使用のページを古くし、最終的にそれらを削除します。これらのページを使用していない間は、気にする必要はありません。
本当の問題は、パフォーマンスが重要なフェーズに到達したときに、TLB が同時に維持できるよりも多くのページを処理するつもりですか? 一方で、最新の CPU には大規模な TLB があり、多くの場合、2 レベルのキャッシュがあります。最新の Intel CPU の L2 TLB には (IIRC) 512 のエントリが必要です。4k ページを使用している場合 (大きなページでよりも多くなっていますが、TLB は通常、小さいページと競合する可能性があるため、それらを使用することを好みません..)。
アプリケーションが 2M を超えるデータを処理する可能性は十分にありますが、キャッシュ タイリングを実行するか、アルゴリズムを変更することにより、同時にこれを行うことはできるだけ避けてください。これは常に可能であるとは限りません (たとえば、メモリまたは IO からのストリーミングの場合)、TLB ミスはおそらく主なボトルネックではありません。同じデータ セットを操作し、同じ要素に複数回アクセスする場合は、それらを可能な限り近くにキャッシュしておくように常に努める必要があります。
また、ソフトウェア プリフェッチを使用して、CPU が TLB ミス (および次のページ ウォーク) を早期に実行するようにし、進行が妨げられるのを防ぐこともできます。一部の CPU では、ハードウェアのプリフェッチが既にこれを行っています。
于 2014-01-10T14:49:13.993 に答える