x86での最悪の場合の実行時間

以前の投稿で 、Atomプラットフォームで割り込みレイテンシを測定する方法と理由について説明しました。



今日は、同じ入力データで同じコードを異なる時間に実行できる理由について説明します。 一部のリアルタイムアプリケーションでは、これは非常に望ましくない効果であり、戦わなければなりません。



念のため、もちろん、現象の本質を理解することなく、見出しの「 最悪のケースの実行時間 」という用語を適用しました。 x86とは接続されていません。



たとえば、DMAを使用して、ハードウェアの一部が新しいデータをメモリに適合させたときに起動する割り込みがあるとします。 ISRでは 、 FIRフィルターを介してそれらを駆動し、たとえば別の鉄片に与えます。 このタスクでなぜx86なのか尋ねないでください。 これは単なる例であり、この例では、マシン上で他の必要なコードの大部分を同時に実行します。



この場合、各割り込みはまったく同じ命令シーケンスを実行することがわかります。 毎回、同時に実行する必要があります。 だから？ そうではありません！



2つの主要なトラップがあります。

1.キャッシュ。 フィルタの係数はメモリから取得されます。 L1Dキャッシュ、L2キャッシュ、L3キャッシュ（存在する場合）、またはメモリに配置できます。 事前に言うことはできません。 この例で仮想メモリが使用された場合、 DTLBミスが発生する可能性があります（または発生しません）。 そして最後に、ISRコード自体をL1Iキャッシュ、L2などに配置できます。 ここでの予測不可能性の主な原因は、以前に実行されたコードがデータでキャッシュを詰まらせる可能性があるという事実です。 また、キャッシュは実コアまたはHTコア間で共有できます。

2.ハイパートレッド。 2番目のスレッドで実行される命令に応じて、最初のスレッドはさまざまな方法でスローダウンします。 （1〜3回、平均でAtomで1.5回）減速メカニズムは、LLCパイプラインを使用したコアと、In-Orderパイプラインを使用したAtomでわずかに異なります。 Atomのハイパートレッドは平均して、互いのパフォーマンスにより強く影響する可能性があります。 キャッシュアクセスなど、より限られたリソースを共有する必要があります。



何ができますか？

1.キャッシュ。 まず、s / wプリフェッチを使用します。 ISRコードの先頭で、まずキャッシュ内のフィルター係数を順序付けます。

新しいコアの一般的なL3キャッシュについて話している場合、別の方法があります。 キャッシュカラーリングを使用して、キャッシュ内のメモリ領域を割り当てることができます。これにより、他のコアで実行されているプロセスを混雑させるのが難しくなります。 OSで仮想メモリを使用して作業にパッチを当てると、一般的な最終レベルキャッシュの特定の領域にのみ分類できる仮想メモリの一部をアプリケーションに付与できます。 コア上のL3キャッシュを32の領域に分割できます。異なるコアにメモリを割り当てるときは、重複しない領域を選択します。 この手法が特定のコードの実行時間を400〜900usから500〜600usに変更するのにどのように役立つかを見ました。

残念ながら、この種の魔法は物理メモリのかなり長い領域には適用できません。



2.ハイパートレッド。 切断する！ パフォーマンスの予測可能性の観点から重要なコードの作業の開始時に、2番目のスレッドにIPIを送信できます。 そして、そのようなIPIを受信すると、たとえばmwaitで待機するハンドラーを作成します。 したがって、ハイパートレッドが提供するパフォーマンスの向上を引き続き使用できますが、望ましくない副作用はほとんどありません。



実際、上記の両方の現象が存在すると、全体的な生産性が向上します。 一部のリアルタイムアプリケーションの場合、小さなもの（100〜500us）の可能性がありますが、予測できない遅延は非常に望ましくありません。 そのため、新しいアーキテクチャに機能が表示され、予測可能なパフォーマンスが得られます。 たとえば、より細かいキャッシュ管理ソフトウェアのサポートが表示される場合があります。