ここではアービトレーションが問題になるとは思いません。その設定を調整するには、ボードのサポートとカーネルの変更が必要です。 VC 拡張機能インターフェースは、Linux カーネルで部分的に処理されます:http://lxr.free-electrons.com/source/drivers/pci/vc.c
私は Linux でカスタム PCIe ボード用のドライバーを作成しましたが、ボード間のトラフィックをルーティングするためのアルゴリズムは、非常に珍しいユース ケース (ほぼリアルタイムのレイテンシー要件を伴う非常に長い転送) がない限り、過去に問題になることはありませんでした。 (この場合、PCIe を使用すべきではありません)。
このタイプのパフォーマンスに直接影響を与える可能性があり、はるかに簡単に対処できるのは、バスのトポロジ自体ですが、影響は通常ほとんど測定できません.
マシンで、lspci コマンドを次のように実行します:
lspci -tv
これにより、PCIe インターフェイスのツリー ビューと、それらが使用する CPU へのルートが表示されます。ほとんどのプロセッサには、CPU に直接接続するスロットと、ブリッジ チップを経由するスロットがあります (Intel x99 チップセットを参照してください
これらのブリッジにより、遅延が発生し、スループットが低下する可能性があります。 CPU ダイレクトは、ビデオ カードなどの高性能デバイス用に特別に構成されています。最初のポイントでは、プロセッサのマイクロ コードの奥深くで、ブリッジされたリンクをさらに劣化させる最適化が行われている可能性があります。 PCIe スロットのパフォーマンスとルーティングの評価をさらに掘り下げるには、sysfs で続けます。
/sys/bus/pci/slots/ の下に、システムの PCI スロット (物理) のリストがあります。バスアドレス<---->物理スロットを関連付ける仮想ファイルです。
/sys/bus/pci/devices の下には、すべてのデバイスのリストがあります (ここで lspci が情報を取得します)。
各デバイスを調べると、それらのカーネルによって公開されているすべての情報、デバイスに関連付けられているドライバー、デバイスに関連付けられている CPU (マルチ CPU システム上) などを確認できます。
編集 - あなたが除外したと思われるいくつかの明白なことについては言及しませんでしたが、念のため:
1. 異なるスロットの両方に、少なくともボードと同じ数のレーンがありますか?
2. 仕様の不一致はありますか? たとえば、ボードは pcie 3、1 つのスロットは 3、もう 1 つは 2 ですか?
3. この懸念について、ボード ベンダーやドライバー開発者と話し合ったことはありますか?彼らはそれに関するいくつかのランダムなエラッタを知っているかもしれません
具体的に教えていただければ具体的なアドバイスができます。
使用しているチップセット/CPU のタイプがわからないため、トポロジー (ダイレクト CPU パス上でより高速なデバイスはどちらか) を見るだけでなく、一般的なアドバイスしか提供できませんが、私が探し始める 3 つの領域で:
割り込みレイテンシ:ボードの割り込みが、高い割り込みレートで他のデバイスを処理している CPU/コアに関連付けられている場合、パフォーマンスが低下します。そのコアで他のカーネル コンテキストの重い作業が行われていますか? /proc/interrupts を監視して、割り込み処理のためにその CPU を使用している他のカーネル モジュールと、それらが発生するカウント/レートを確認します。 /proc/irw ... smp_affinity でそのデバイスの CPU アフィニティを調整してみてください。 smp アフィニティはマスクです。8 つのコアがあり、何も指定しない場合は、FF (8 つの 1) に設定されます。たとえば、次のように設定した場合。 0x02、これは Core 2 に IRQ の処理を強制します。特定の問題に対処していることがわかっていない限り、これらの変更を強制すると事態が悪化する可能性があります。
割り込みサポート:デバイスの 1 つが MSI-x または MSI 割り込みを使用しているかどうかを確認し、もう 1 つのデバイスが標準 (電気的) 割り込みを使用しているかどうかを確認します。ブリッジがボードの MSI 実装をサポートしていない場合があります (MSI は、バス自体を介して送信される単なるパケットである電気的割り込みではなく、メッセージ信号による割り込みを意味します)。通常、デバイスが複数の割り込みを使用しているにもかかわらず、そのために 1 つの割り込みだけで動作する必要がある場合、直接探していない限り検出が難しく、パフォーマンスの問題が発生する可能性があります。
パフォーマンスを特徴付けます。カーネルには、パフォーマンス データを収集するためのツールが多数あります。それらすべてに共通していることの 1 つは、文書化が不十分であり、一般的にサポートされていないことです。しかし、そうは言っても、Ftrace を使用して、各ボードからの dma 転送とそれぞれの IRQ レイテンシを特徴付けることに注目します。外れ値イベントに関する特定の詳細だけでなく、統計情報も取得できます。ここで調査を開始できます:http://elinux.org/Ftrace
一般に、修正しようとしていること (修正する症状ではなく、根本的な原因) を可能な限り完全に理解することなく、非常に低レベルの設定でいじくり回すことは強くお勧めしません。 99% の確率で、そのために「ノブ」を回すことになりますが、元の問題が何であるかを理解せずに、特定の設定の有効性をどのように評価できますか (即時および長期安定性の観点から)。 .
私は一般的なカーネル デバッグに ftrace を多用しており、強くお勧めします。物事を少し抽象化したい場合は、ftrace を使いやすくすると主張するラッパーがありますが、追加の抽象化が水を濁らせるだけであることがわかりました-trace-cmd、カーネルサメなど。レッドハットシステムを使用している場合systemtap を調べることができます - 同じものではありませんが、同様のデータを提供できます (十分にサポートされています)。