5

ハードウェア デバイスがいっぱいになるまで最大 1MB のバッファーを必要とするアプリがあるため、kmalloc() を使用してバッファーを割り当てるカーネル モジュールを作成しました。dma_alloc_coherent() は使用しませんでした。バッファーを操作する必要があるため、バッファーをキャッシュする必要があったためです (必要に応じてキャッシュをフラッシュします)。実行される操作の 1 つは、カーネル モジュールが 1 つのバッファーを別のバッファーにコピーすることです。これらのコピーのタイミングでは、バッファをコピーするのに約 2 ミリ秒かかることがわかります。この時間には、キャッシュのフラッシュは含まれていません。

これは遅いように見えたので、malloc() を使用して 1MB のバッファーを作成し、それらをコピーする標準のユーザー空間テスト アプリを作成しました。ユーザー空間のコピーには約 0.5 ミリ秒かかりました。これは、使用しているプロセッサ/メモリ構成でこの量のメモリを移動するのに適切な時間です。

試してみたこと: カーネル空間とユーザー空間で異なる memcpy() でないことを確認するために、独自の NEON 最適化コピーを作成しましたが、違いはありませんでした。バッファ サイズを 100KB から 10MB に変更しましたが、違いはありませんでした。すべての回で 10 部以上のコピーがありましたが、常に非常に一貫性がありました。時間ルーチンは、ユーザー空間で gettimeofday() を使用しました。

私たちが考えることができる唯一のことは、データキャッシュが kmalloc() されたメモリと malloc() されたメモリで異なるように設定されているということです???

iMX6 ARM、Linaro kerne に取り組んでいます。

4

1 に答える 1

2

メモリはkmalloc()物理空間で隣接します。ユーザースペースは絶対にありません（mlock()隣接に近づく可能性があります）。複数のSDRAMチップがある場合は、メモリコントローラで、 異なるチップへのパイプライン処理または複数の問題の読み取り/書き込みを同時に許可できる可能性があります。複数のバンクを使用すると、さらに高速になる場合があります。 vmalloc()連続したページは使用しません。Refkmalloc()と交換する テストを作成できるはずですvmalloc()。新しいARMで何かが変更され、キャッシュがVIVTでない場合、物理アドレスの違いにより、一部のプロセッサにキャッシュ（エイリアシング？）の影響が生じる可能性があります。

キャッシュはカーネルメモリとユーザーメモリで異なって設定されているとは思いません。少なくとも2.6.34のバリアントでは。しかし、それらは異なるプールから来ている可能性があります。また、memcpy()大きなキャッシュの場合は必要ありません。SDRAMがバーストすることを確認するのに十分なだけです。

もう1つの問題は周辺機器です。たとえば、1つのチップ上の大きなグラフィックバッファは、DMAを介してサイクルを盗む可能性があります。マシンファイルまたはデバイステーブルを変更して、できるだけ多くのドライバーを無効にできる場合は、これを排除できます。これをパイプラインと組み合わせると、観察された速度低下のタイプを説明できます。

これはプラットフォームの問題だと思います。厳密にLinuxだったとしたら、何百万人ものユーザーの1人がLinuxに遭遇したのではないかと思います。ただし、Linuxの特定のバージョンを指定していません。ARMベースの問題である可能性があります。だから私はそれをそのようにタグ付けしました。プラットフォームとARMの組み合わせだと思います。他の人がこれを観察するという理由だけで。また、設計の基になっている特定のマシンファイルまたはデバイステーブルとLinuxバージョンを提供できますか。

于 2013-03-20T04:06:36.720 に答える