PCIeデバイスに設定されたアービトレーションスキームを変更するために呼び出すことができるLinuxシステムコマンドはありますか？
PCIeボードをプローブすると、システム内のすべてが固定アービトレーションスキームに設定されていることがわかります。私の読書から、このスキームはベンダーに任されています（私が想定しているのは私たちのOSです）。
さまざまなアービトレーションスキームを試して、DMAレートにどのように影響するかを確認したいと思います。
コンテキストとして、6つのPCIeスロット（CPU1用に3つ、CPU2用に3つ）を備えたデュエルソケットマザーボードがあります。ボードの1つは1つのCPUのスロットにあり、もう1つのボードはCPU2のスロットにあります。それらは、同じソフトウェアが実行されている同じボードです。 DMAデータをシステムメモリからボード上にあるメモリに転送します。DMAレートは2つのボード間で異なり、通常、一方が他方よりも常に高速です。かなりの割合で搭乗します。
当社のPCベンダーは、異なるPCIeスロットで、あるボードが別のボードよりも優先されているように見えるこの不一致を他の顧客が見ていることを確認しました。
このポートVC機能レジスタを利用してアービトレーションスキームを変更する方法はありますか？
アービトレーションスキームを調整する正しいレジスタをリストしなかった場合、どれが正しいか教えていただけますか？
ここではアービトレーションが問題になるとは思いません。その設定を調整するには、ボードのサポートとカーネルの変更が必要です。 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、他のスロットは2ですか？
3。この懸念について、ボードベンダーやドライバー開発者と、iyを認めている以上に話し合ったことはありますか？彼らはそれに関するいくつかのランダムな正誤表に気づいているかもしれません
あなたが特定の詳細を提供するならば、私は特定のアドバイスを提供することができます。
トポロジ（直接CPUパス上でより高速なデバイスであり、他はそうではない）を確認する以外に、使用しているチップセット/ CPUのタイプがわからない場合は、一般的なアドバイスしか提供できませんが、3つの領域を検討し始めます。で：
割り込みレイテンシ：ボードの割り込みが、高い割り込み率で他のデバイスを処理しているCPU /コアに関連付けられている場合、パフォーマンスが低下します。そのコアで起こっている他のカーネルコンテキストの重労働はありますか？/proc/interruptsを監視して、割り込み処理のためにそのCPUを使用している他のカーネルモジュールと、それらが発生するカウント/レートを確認します。/proc/irw ... smp_affinityでそのデバイスのCPUアフィニティを調整してみてください。 smpアフィニティはマスクです。コアが8つあり、何も指定しなかった場合は、FF（8 1）に設定されます。に設定した場合、たとえば0x02、これによりCore2がIRQを処理するように強制されます。特定の問題に対処していることがわかっていない限り、これらの変更を強制すると、事態が悪化する可能性があります。
割り込みサポート：デバイスの1つがMSI-xまたはMSI割り込みを使用しているかどうかを確認し、もう1つは標準（電気）割り込みを使用しています。ブリッジがボードのMSI実装をサポートしていない場合があります（MSIは、メッセージ信号による割り込みを意味します。電気的な割り込みではなく、バス自体を介して送信されるパケットだけです）。デバイスが通常複数の割り込みを使用しているが、これが原因で1つの割り込みのみで動作する必要がある場合、直接探していない限り検出が難しく、パフォーマンスの問題が発生する可能性があります。
パフォーマンスを特徴付けます。カーネルには、パフォーマンスデータを収集するための多くのツールがあります。それらすべてに共通していることの1つは、文書化が不十分で、一般的にサポートされていないことです。しかし、そうは言っても、Ftraceを使用して、各ボードからのdma転送と、それぞれのIRQレイテンシーを特徴付けることを検討します。外れ値イベントの統計情報と特定の詳細を取得できます。ここでそれを調べ始めることができます： http://elinux.org/Ftrace
一般に、修正しようとしている内容（修正する症状ではなく、根本的な原因）を可能な限り完全に理解せずに、非常に低いレベルの設定をいじくり回すことは強くお勧めしません。 99％の確率で、そのために「ノブ」を回すことになりますが、元の問題が何であるかを理解せずに、特定の設定の有効性をどのように評価できますか（即時および長期安定性の両方の観点から） 。
私は一般的なカーネルデバッグにftraceを多用しており、強くお勧めします。物事を少し抽象化したい場合は、使いやすくすると主張するftraceのラッパーがありますが、追加の抽象化は水を濁らせるだけです-trace-cmd、kernelsharkなど。RedHatシステムを使用している場合systemtapを調べることができます-同じことではありませんが、同様のデータを提供できます（そしてそれは十分にサポートされています）。
PCIeブリッジング（スイッチング）のレベルを追加すると、遅延応答とスループットに影響を与える可能性がありますが、これによるパフォーマンスの違いにより、私の経験はそれほど大きくありません。より一般的で、ほぼ確実に発生している問題は、ユーザースペースアプリケーションや、さまざまなHBAカードに割り当てられているデバイスドライバーのメモリバッファーが、実際には2つのCPUのいずれかに割り当てられていることです。この場合はCPU1で。その結果、CPU2に接続されたデバイスによって開始されたメモリとの間のすべてのDMAは、CPU1に接続されたものよりも遅くなります。これは、関連するすべてのシステムメモリが実際には特定のワークロードのCPU1でホストされているためです。 。アプリケーションメモリの場合、これは一般的であり、それについてできることはあまりありません。（より洗練されたアプリケーションの場合、メモリの割り当て元に影響を与える可能性のある環境変数またはコマンドラインオプションに基づくスイッチがあるアプリケーションや、一部のアプリケーション異なるプロセスに対して、異なるCPUで、異なるメモリを割り当てます。ただし、これらのアプリケーションは少なく、ほとんどの場合、そのような制御は提供されません。）
デバイスドライバー（ここでユーザーが制御できると仮定）は、NUMA対応の方法でメモリを割り当てる手順を実行できます。具体的には、I/Oデバイスに最も近いCPUノードにドライバーバッファーを割り当てます。これには、デバイスドライバーで文書化された追加の手順が必要ですが、これらの追加の手順を実行するデバイスドライバーはほとんどありません。 （ある人はそうする）。これが行われ、デバイスドライバーが実際にユーザーからカーネルバッファー（現在はNUMAが割り当てられている）にデータをコピーする場合（そしてその場合のみ）、DMA用の2つのHBAカード間で同じパフォーマンスが見られるはずです。 （アプリケーションのメモリ（元のコピー元）は通常すべてに割り当てられているため、2枚のカードのいずれかでユーザースペースからカーネルスペースへのコピーが遅くなるため、全体的なトランザクション速度はどちらか一方に遅くなる可能性があります。 1つの特定のCPUノード（例ではCPU1）であり、CPU1のユーザーからカーネルスペースのバッファーに移動するよりも、CPU2のユーザースペースからカーネルスペースにコピーするのに時間がかかります。すべてのマルチソケットシステムでこの問題が発生しますが、一部のシステムでは、CPU間相互接続（QuickPath、UPI、Hypertransportなど）の速度に基づいて、問題が他のシステムよりも悪化します。
デバイスドライバが割り当てられたノード固有のメモリの問題に直面した場合でも、それが常に役立つとは限りません。まず、多くの場合、ドライバーは最初にカーネルスペースバッファーにコピーするのではなく、デバイスDMA（ゼロコピーDMA））にダイレクトユーザースペースを実行している可能性があります。この場合、関連するカーネルバッファーはありません。次に、デバイスドライバーにノード固有のメモリがあり、そのメモリがデバイスドライバーによって使用されている場合でも、ユーザースペースからカーネルスペースへのコピーの遅延の差が見られます（ノードに隣接する方法で割り当てることができます）。ニアHBAからニアカーネルメモリへのコピーは高速です）、ファーHBA（ここではCPU2）、およびファーCPU2デバイスメモリ（存在する場合）は低速です。このような場合、これは問題を不等から「移動」しますDMA速度、代わりにカーネルスペースバッファコピーに対してユーザースペースが「等しくない」ようになります。DMA時間は等しくなりますが、トランザクション時間（ユーザーからカーネルコピーを含む）は等しくなります。この後者の理由は、多くのデバイスドライバーライターがノード固有のメモリをわざわざ割り当てない理由の1つです（もう1つのメイン理由は単純な無知です。）
いずれの場合も、メモリアクセス速度の違いによる時間ペナルティは、PCIeスイッチング遅延の違いによる時間ペナルティよりもほぼ確実にはるかに大きくなります。
エンドユーザーとして、あなたにできることはほとんどありません。デバイスドライバーライターとして、デバイスドライバーでNUMA対応のメモリ割り当て手法を利用できます。ワークロードによっては、これが非常に役立つ場合もあれば、まったく役に立たない場合もあります。
デバイスドライバーとソースアプリケーションの両方にNUMA対応の方法でメモリを割り当てることができない限り（アプリケーションの場合、データが因数分解される方法のため、これは多くの場合困難または不可能です）、この不均一な速度を打ち負かすことはできません。違いの問題。