ARMマイクロプロセッサのキャッシュについて

こんにちは！



前回の記事では、プロセッサキャッシュを使用して、Emboxのマイクロコンピュータのグラフィックスを高速化しました。この場合、「ライトスルー」モードを使用しました。次に、「ライトスルー」モードに関連するいくつかの長所と短所について説明しましたが、これは大まかな概要にすぎませんでした。この記事では、約束どおり、ARMマイクロプロセッサのキャッシュの種類を詳しく調べて比較したいと思います。もちろん、これはすべてプログラマーの観点から検討されます。この記事では、メモリーコントローラーの詳細については説明しません。



前回の記事で停止したところ、つまり「ライトバック」モードと「ライトスルー」モードの違いから始めます。これらの2つのモードが最も頻繁に使用されるためです。要するに：

• "返事を書く"。書き込みデータはキャッシュにのみ送られます。メモリへの実際の書き込みは、キャッシュがいっぱいになり、新しいデータ用のスペースが必要になるまで延期されます。
• 「ライトスルー」。キャッシュとメモリへの書き込みは「同時に」行われます。

ライトスルー

ライトスルーの利点は使いやすさであると考えられており、エラーを減らす可能性があります。実際、このモードでは、メモリは常に正しい状態にあり、追加の更新手順は必要ありません。



もちろん、これはパフォーマンスに大きな影響を与えるはずですが、このドキュメントのSTM自体は、そうではないと述べています。

Write-through: triggers a write to the memory as soon as the contents on the cache line are written to. This is safer for the data coherency, but it requires more bus accesses. In practice, the write to the memory is done in the background and has a little effect unless the same cache set is being accessed repeatedly and very quickly. It is always a tradeoff.

つまり、最初は書き込みがメモリへの書き込みであるため、書き込み操作のパフォーマンスはキャッシュがない場合とほぼ同じであり、読み取りが繰り返されるために主なゲインが発生すると想定していました。ただし、STMはこれに異議を唱え、メモリ内のデータは「バックグラウンド」になるため、書き込みパフォーマンスは「ライトバック」モードとほぼ同じであると述べています。これは、特に、メモリコントローラ（FMC）の内部バッファに依存する場合があります。



「ライトスルー」モードのデメリット：

• 同じメモリへのシーケンシャルで高速なアクセスは、パフォーマンスを低下させる可能性があります。「ライトバック」モードでは、逆に、同じメモリへの連続した頻繁なアクセスはプラスになります。
• 「ライトバック」の場合と同様に、DMA操作の終了後にキャッシュの無効化を行う必要があります。
• Cortex-M7の一部のバージョンで、「一連のライトスルーストアおよびロードでのデータ破損」のバグ。それはされた指摘に私たちLVGLの開発者の一人で。

返事を書く

上記のように、このモードでは（「ライトスルー」とは対照的に）、データは通常、書き込みによってメモリに入るのではなく、キャッシュに入るだけです。ライトスルーと同様に、この戦略には2つのサブオプションがあります。1）書き込み割り当て、2）書き込み割り当てなし。これらのオプションについてさらに説明します。

書き込み割り当て

原則として、「読み取り割り当て」は常にキャッシュで使用されます。つまり、読み取りのキャッシュミスが発生すると、データがメモリからフェッチされ、キャッシュに配置されます。同様に、書き込みミスが発生した場合、データをキャッシュにロードする（「書き込み割り当て」）か、ロードしない（「書き込み割り当てなし」）ことができます。



通常、実際には、「ライトバック書き込み割り当て」または「ライトスルー書き込み割り当てなし」の組み合わせが使用されます。さらにテストでは、「書き込み割り当て」を使用する状況と「書き込み割り当てなし」を使用する状況について、もう少し詳しく確認します。

MPU

実際の部分に進む前に、メモリ領域のパラメータを設定する方法を理解する必要があります。ARMv7-Mアーキテクチャのメモリの特定の領域に対してキャッシュモードを選択（または無効化）するには、MPU（メモリ保護ユニット）を使用します。



MPUコントローラは、メモリ領域の設定をサポートしています。具体的には、ARMV7-Mアーキテクチャでは、最大16のリージョンが存在する可能性があります。これらのリージョンでは、開始アドレス、サイズ、アクセス権（読み取り/書き込み/実行など）、属性-TEX、キャッシュ可能、バッファ可能、共有可能、およびその他のパラメータを個別に設定できます。特に、このようなメカニズムを使用すると、特定のリージョンに対して任意のタイプのキャッシングを実現できます。たとえば、すべてのDMA操作にメモリの領域を割り当て、そのメモリをキャッシュ不可としてマークするだけで、cache_clean / cache_invalidateを呼び出す必要をなくすことができます。



MPUを使用する際の注意点：

リージョンのベースアドレス、サイズ、および属性はすべて構成可能であり、一般的なルールでは、すべてのリージョンが自然に整列されます。これは次のように

表すことができます。RegionBaseAddress[（N-1）：0] = 0、ここでNはlog2（SizeofRegion_in_bytes）

つまり、メモリ領域の開始アドレスを独自のサイズに揃える必要があります。たとえば、16 Kbの領域がある場合は、16Kbで位置合わせする必要があります。メモリ領域が64Kbの場合は、64Kbに揃えます。等々。これが行われない場合、MPUは、開始アドレスに対応するサイズに領域を自動的に「トリミング」できます（実際にテスト済み）。



ちなみに、STM32Cubeにはいくつかのバグがあります。例えば：

  MPU_InitStruct.BaseAddress = 0x20010000;
  MPU_InitStruct.Size = MPU_REGION_SIZE_256KB;

開始アドレスが64KBに揃えられていることがわかります。また、領域のサイズを256KBにする必要があります。この場合、最初の64 Kb、2番目の128 Kb、3番目の64Kbの3つの領域を作成する必要があります。



標準のプロパティとは異なる領域を指定するだけで済みます。実際には、プロセッサキャッシュが有効になっている場合のすべてのメモリの属性は、ARMアーキテクチャで記述されています。プロパティの標準セットがあります（たとえば、これがSTM32F7 SRAMにデフォルトで「ライトバック書き込み割り当て」モードがある理由です）。したがって、一部のメモリに非標準モードが必要な場合は、MPUを介してプロパティを設定する必要があります。この場合、リージョン内で、独自のプロパティを持つサブリージョンを設定できます。このリージョン内で、必要なプロパティを持つ優先度の高い別のサブリージョンを強調表示します。

TCM

ドキュメント（セクション2.3組み込みSRAM） からわかるように、STM32F7のSRAMの最初の64KBはキャッシュできません。ARMv7-Mアーキテクチャ自体では、SRAMは0x20000000にあります。TCMはSRAMも指しますが、残りのメモリ（SRAM1およびSRAM2）とは異なるバス上にあり、プロセッサの「近く」にあります。このため、このメモリは非常に高速であり、実際、キャッシュと同じ速度です。このため、キャッシュは不要であり、この領域をキャッシュ可能にすることはできません。実際、TCMもそのようなキャッシュです。

命令キャッシュ

上記で説明したものはすべて、データキャッシュ（D-Cache）を参照していることに注意してください。ただし、ARMv7-Mは、データキャッシュに加えて、命令キャッシュ（命令キャッシュ（I-Cache））も提供します。I-Cacheを使用すると、実行可能な（および後続の）命令の一部をキャッシュに転送できます。これにより、プログラムを大幅に高速化できます。特に、QSPIなど、コードがFLASHよりも遅いメモリにある場合。



以下のキャッシュを使用したテストでの予測不可能性を減らすために、意図的にI-Cacheを無効にし、データのみを考慮します。



同時に、I-Cacheをオンにすることは非常に簡単であり、D-Cacheとは異なり、MPUからの追加のアクションを必要としないことに注意したいと思います。

合成テスト

理論的な部分について説明した後、特定のモデルの違いと適用範囲をよりよく理解するために、テストに移りましょう。上で述べたように、I-Cacheを無効にし、D-Cacheでのみ機能します。また、テストのループが最適化されないように、意図的に-O0を使用してコンパイルします。外部SDRAMメモリを介してテストします。 MPUの助けを借りて、64 KBの領域にマークを付け、この領域に必要な属性を公開します。



キャッシュを使用したテストは非常に気まぐれであり、システム内のすべてのものとすべての人の影響を受けるため、コードを線形で連続的にしましょう。これを行うには、割り込みを無効にします。また、タイマーでは時間を測定しませんが、プロセッササイクルの32ビットカウンタを備えたDWT（データウォッチポイントおよびトレースユニット）を測定します。その上で（インターネット上で）人々はドライバーにマイクロ秒の遅延を作ります。カウンタは216MHzのシステム周波数ですぐにオーバーフローしますが、最大20秒まで測定できます。これを念頭に置いて、この時間間隔でテストを行い、開始する前にクロックカウンターを事前にゼロにします。



完全なテストコードはここで確認できます。すべてのテストは、32F769IDISCOVERYボードで実行されました。

キャッシュ不可能なメモリVS。返事を書く

それでは、いくつかの非常に簡単なテストから始めましょう。



一貫してメモリに書き込みます。

    dst = (uint8_t *) DATA_ADDR;

    for (i = 0; i < ITERS * 8; i++) {
        for (j = 0; j < DATA_LEN; j++) {
            *dst = VALUE;
            dst++;
        }
        dst -= DATA_LEN;
    }

また、メモリに順番に書き込みますが、一度に1バイトではありませんが、ループを少し拡張します。

    for (i = 0; i < ITERS * BLOCKS * 8; i++) {
        for (j = 0; j < BLOCK_LEN; j++) {
            *dst = VALUE;
            *dst = VALUE;
            *dst = VALUE;
            *dst = VALUE;
            dst++;
        }
        dst -= BLOCK_LEN;
    }

また、メモリに順次書き込みますが、ここで読み取りも追加します。

    for (i = 0; i < ITERS * BLOCKS * 8; i++) {
        dst = (uint8_t *) DATA_ADDR;

        for (j = 0; j < BLOCK_LEN; j++) {
            val = VALUE;
            *dst = val;
            val = *dst;
            dst++;
        }
    }

これら3つのテストをすべて実行すると、どのモードを選択しても、まったく同じ結果が得られます。

mode: nc, iters=100, data len=65536, addr=0x60100000
Test1 (Sequential write):
  0s 728ms
Test2 (Sequential write with 4 writes per one iteration):
  7s 43ms
Test3 (Sequential read/write):
  1s 216ms

そして、これは合理的です。特に、SDRAMが接続されているFMCの内部バッファーを考慮すると、SDRAMはそれほど遅くはありません。それにもかかわらず、私は数のわずかな変動を予想しました、しかしそれはこれらのテストになかったことがわかりました。さて、さらに考えてみましょう。



読み取りと書き込みを組み合わせて、SDRAMの寿命を「台無し」にしてみましょう。これを行うには、ループを拡張して、実際には配列要素の増分などの一般的なものを追加しましょう。

    for (i = 0; i < ITERS * BLOCKS; i++) {
        for (j = 0; j < BLOCK_LEN; j++) {
            // 16 lines
            arr[i]++;
            arr[i]++;
	***
            arr[i]++;
        }
    }

結果：

  :   4s 743ms
Write-back:                     :   4s 187ms

すでに優れています-キャッシュを使用すると、0.5秒速くなることがわかりました。テストをさらに複雑にしてみましょう。「スパース」インデックスによるアクセスを追加します。たとえば、1つのインデックスがある場合：

    for (i = 0; i < ITERS * BLOCKS; i++) {
        for (j = 0; j < BLOCK_LEN; j++) {
            arr[i + 0 ]++;
            ***
            arr[i + 3 ]++;
            arr[i + 4 ]++;
            arr[i + 100]++;
            arr[i + 6 ]++;
            arr[i + 7 ]++;
            ***
            arr[i + 15]++;
        }
    }

結果：

  :   11s 371ms
Write-back:                     :   4s 551ms

これで、キャッシュとの違いが目立つようになりました。さらに、そのような2番目のインデックスを紹介します。

    for (i = 0; i < ITERS * BLOCKS; i++) {
        for (j = 0; j < BLOCK_LEN; j++) {
            arr[i + 0 ]++;
            ***
            arr[i + 4 ]++;
            arr[i + 100]++;
            arr[i + 6 ]++;
            ***
            arr[i + 9 ]++;
            arr[i + 200]++;
            arr[i + 11]++;
            arr[i + 12]++;
            ***
            arr[i + 15]++;
        }
    }

結果：

  :   12s 62ms
Write-back:                     :   4s 551ms

キャッシュされていないメモリの時間がほぼ1秒増加し、キャッシュの場合は同じままであることがわかります。

書き込み割り当てVS。書き込み割り当てなし

それでは、「書き込み割り当て」モードを扱いましょう。ここで違いを確認するのはさらに困難です。キャッシュされていないメモリと「ライトバック」の間の状況で、4番目のテストからすでに明確に表示されている場合、「書き込み割り当て」と「書き込み割り当てなし」の違いはテストによってまだ明らかにされていません。考えてみましょう-「書き込み割り当て」が速くなるのはいつですか？たとえば、シーケンシャルメモリ位置への書き込みが多く、それらのメモリ位置からの読み取りが少ない場合です。この場合、「書き込み割り当てなし」モードでは、常にミスが発生し、読み取りによって間違った要素がキャッシュにロードされます。この状況をシミュレートしてみましょう。

    for (i = 0; i < ITERS * BLOCKS; i++) {
        for (j = 0; j < BLOCK_LEN; j++) {
            arr[j + 0 ]  = VALUE;
            ***
            arr[j + 7 ]  = VALUE;
            arr[j + 8 ]  = arr[i % 1024 + (j % 256) * 128];
            arr[j + 9 ]  = VALUE;
            ***
            arr[j + 15 ]  = VALUE;
        }
    }

ここでは、16レコードのうち15レコードがVALUE定数に設定され、読み取りは異なる（書き込みとは関係のない）要素から実行されますarr [i％1024 +（j％256）* 128]。書き込み割り当てなしの戦略では、これらの要素のみがキャッシュにロードされることがわかります。このようなインデックスが使用される理由（i％1024 +（j％256）* 128）は、FMC / SDRAMの「速度低下」です。大幅に異なる（非順次）アドレスでのメモリアクセスは、作業速度に大きな影響を与える可能性があるためです。



結果：

Write-back                                           :   4s 720ms
Write-back no write allocate:               :   4s 888ms

最後に、それほど目立たないものの、すでに目に見える違いがありました。つまり、私たちの仮説が確認されました。



そして最後に、私の意見では、最も難しいケースです。「書き込み割り当てなし」が「書き込み割り当て」よりも優れている場合を理解したいと思います。近い将来に使用しないアドレスを「頻繁に」参照する場合は、最初の方が適しています。このようなデータをキャッシュする必要はありません。



次のテストでは、「書き込み割り当て」の場合、データは読み取りと書き込みで入力されます。64KBの配列「arr2」を作成したので、新しいデータを交換するためにキャッシュがフラッシュされます。「書き込み割り当てなし」の場合、4096バイトの「arr」配列を作成しましたが、それだけがキャッシュに入ります。つまり、キャッシュデータはメモリにフラッシュされません。このため、少なくとも小さな勝利を目指します。

    arr = (uint8_t *) DATA_ADDR;
    arr2 = arr;

    for (i = 0; i < ITERS * BLOCKS; i++) {
        for (j = 0; j < BLOCK_LEN; j++) {
            arr2[i * BLOCK_LEN            ] = arr[j + 0 ];
            arr2[i * BLOCK_LEN + j*32 + 1 ] = arr[j + 1 ];
            arr2[i * BLOCK_LEN + j*64 + 2 ] = arr[j + 2 ];
            arr2[i * BLOCK_LEN + j*128 + 3] = arr[j + 3 ];
            arr2[i * BLOCK_LEN + j*32 + 4 ] = arr[j + 4 ];
            ***
            arr2[i * BLOCK_LEN + j*32 + 15] = arr[j + 15 ];
        }
    }

結果：

Write-back                                           :   7s 601ms
Write-back no write allocate:               :   7s 599ms

「ライトバック」「ライトアロケーション」モードの方がわずかに高速であることがわかります。しかし、重要なことはそれがより速いということです。



これ以上のデモンストレーションは得られませんでしたが、違いがより明確になる実際的な状況があると確信しています。読者は自分のオプションを提案することができます！

実例

合成の例から実際の例に移りましょう。

ping

最も簡単なものの1つはpingです。開始は簡単で、時間はホストで直接表示できます。Emboxは-O2最適化で構築されました。すぐに結果をお伝えしましょう。

    :  ~0.246 c
Write-back                        :  ~0.140 c

Opencv

キャッシュサブシステムを試してみたかった実際の問題のもう1つの例は、STM32F7のOpenCVです。その記事では、起動はかなり可能であることが示されていましたが、パフォーマンスはかなり低かったです。デモンストレーションでは、Cannyフィルターに基づいて境界線を抽出する標準的な例を使用します。キャッシュ（DキャッシュとIキャッシュの両方）がある場合とない場合の実行時間を測定してみましょう。

   gettimeofday(&tv_start, NULL);

    cedge.create(image.size(), image.type());
    cvtColor(image, gray, COLOR_BGR2GRAY);

    blur(gray, edge, Size(3,3));
    Canny(edge, edge, edgeThresh, edgeThresh*3, 3);
    cedge = Scalar::all(0);

    image.copyTo(cedge, edge);

    gettimeofday(&tv_cur, NULL);
    timersub(&tv_cur, &tv_start, &tv_cur);

キャッシュなし：

> edges fruits.png 20 
Processing time 0s 926ms
Framebuffer: 800x480 32bpp
Image: 512x269; Threshold=20

キャッシュあり：

> edges fruits.png 20 
Processing time 0s 134ms
Framebuffer: 800x480 32bpp
Image: 512x269; Threshold=20

つまり、926msと134msの加速はほぼ7倍です。



実際、STM32のOpenCVについて、特にパフォーマンスについてよく尋ねられます。FPSは確かに高くはありませんが、1秒あたり5フレームを取得するのは非常に現実的です。

キャッシュ可能またはキャッシュされたメモリではありませんが、キャッシュを無効にしますか？

実際のデバイスでは、DMAが広く使用されていますが、「ライトスルー」モードでもメモリを同期する必要があるため、当然、DMAには問題が伴います。キャッシュされないメモリを単に割り当てて、DMAを使用するときにそれを使用したいというのは当然のことです。少し気が散る。 Linuxでは、これはdma_coherent_alloc（）を介した関数によって実行されます。はい、これは非常に効果的な方法です。たとえば、OSでネットワークパケットを操作する場合、ユーザーデータはドライバーに到達する前に処理の大きな段階を経て、ドライバーでは、すべてのヘッダーを含む準備されたデータが、キャッシュされていないメモリを使用するバッファーにコピーされます。



DMAを備えたドライバーでクリーン/無効化が望ましい場合はありますか？はいあります。たとえば、私たちを促したビデオメモリcache（）がどのように機能するかを詳しく見てみましょう。ダブルバッファリングモードでは、システムには2つのバッファがあり、そこに順番に引き込まれ、ビデオコントローラに渡されます。このようなメモリをキャッシュ不可にすると、パフォーマンスが低下します。したがって、バッファをビデオコントローラに送信する前に、クリーンアップを実行することをお勧めします。

結論

ARMv7mのさまざまなタイプのキャッシュについて少し理解しました。ライトバック、ライトスルー、および「書き込み割り当て」と「書き込み割り当てなし」の設定です。あるモードが他のモードよりも優れていることを確認するための合成テストを作成し、pingとOpenCVを使用した実際的な例も検討しました。Emboxでは、このトピックに取り組んでいるだけなので、対応するサブシステムはまだ検討中です。ただし、キャッシュを使用する利点は間違いなく顕著です。



すべての例は、オープンリポジトリからEmboxをビルドすることで表示および複製できます。



PS



あなたは、システムのプログラミングとOSDevの話題に興味がある場合は、OSの日の会議が明日開催されます！今年はオンラインですので、お見逃しなく！Emboxは明日12.00に演奏します