Linuxカーネルのサイズ計算に関するバグにより、PCIeスイッチ配下で接続された複数の32 GB Resizable BAR(Base Address Registers)をマッピングできず、結果としてGPU間の高性能なピア・ツー・ピア(P2P)通信がブロックされることがあります。これは、カーネルが大きなメモリブロックと小さなレジスタウィンドウの間のアライメント・ギャップを収容するために必要なアドレス空間の量を過小評価するために発生します。
アライメント・ギャップの問題
GPUがResizable BARを使用する場合、32 GBなどのVRAM全体をCPUのアドレス空間にマッピングします。しかし、多くのGPUはドライバとの通信のために小さな「ドアベル」BARも必要とします。これらの大きなBARは特定の境界(例:32 GB)から開始しなければならないため、32 GBのBARの直後に配置された2 MBのドアベルであっても、次のデバイスは次の32 GBのインクリメントから開始することを強制されます。
Linux 7.0カーネルの`pbus_size_mem()`関数にはリグレッションが含まれています。この関数は、子要素のサイズを合計することでスイッチの総ウィンドウを計算します。これらを単純な合計として扱い、アライメント・ギャップを考慮しないため、カーネルはカードが実際に占有するよりも小さなスペースに収まると判断し、「can't assign; no space(割り当て不可:スペースなし)」というエラーを引き起こします。

このイラストは、実際のアライメント要件があるにもかかわらず、カーネルが利用可能なスペースが十分であると信じ込んでいるサイズ計算バグの視覚的なメタファーです。
「カーネルはスイッチに約128.6 GBのウィンドウを与えました。各BARの後にドアベルを配置したLinux 7.0のレイアウトでは、4つのウィンドウが224 GB(3つの64 GBスロットと、最後のカードの32 GBおよびそのドアベル)に及びます。」
— Fitting Four 32 GB Resizable BARs Behind a PCIe Switch on Linux
この図は、カーネルの「単純な合計」計算が、大きなBARに必要とされる32 GBのパディングを考慮できないという特定のアライメント・ギャップの問題を説明しています。
カーネルのサイズ計算バグの回避
この問題を解決するために、カスタムカーネルモジュール(`gpu-rebar-layout`)が、GPUドライバがロードされる前にカーネルが起動する小さなファイルシステムであるinitramfs内で動作します。このモジュールはターゲットとなるGPUを特定し、それらのBAR0サイズを最大サポートサイズ(例:32 GB)に設定し、その後、PCIeスイッチより上のルートポートを削除して再スキャンします。
この再スキャン中に、モジュールはすべての小さなメモリBARのアライメントを、そのセグメントの最大のBARに合わせて手動で引き上げます。これにより、各R9700ウィンドウが正確に64 GBのアドレス空間を占有することが保証され、カーネルのアロケータはすべてのデバイスを重複やスペース不足なしに正常に配置できるようになります。
パフォーマンスの向上とトレードオフ
これらのBARを正しくマッピングすることは、GPUがCPUを介さずに互いにデータをコピーできるピア・ツー・ピア(P2P)通信にとって極めて重要です。4枚のAMD Radeon AI PRO R9700を使用したテストでは、この構成によりペアあたり14.0 GB/sを達成し、4枚のカードがリング状にコピーを行うことで合計54.7 GB/sを記録しました。
この回避策には特定のトレードオフが含まれます。ブートプロセスの非常に早い段階でロードする必要があり、より多くのアドレス空間を確保するためにGPUオーディオ機能を無効にする必要がある場合があります。さらに、このサイズ計算バグを適切に修正するための14パッチの修正シリーズが現在Linuxカーネル向けに開発中ですが、現在のバージョンではこのモジュールが不可欠な回避策となります。
Hacker Newsの読者の反応
- 代替案: コメンターは、投稿者が4枚のGPU間のピア・ツー・ピア転送を可能にするためにモジュールを開発したこと、およびこの機能を無効にするとプリフィルタスク中のパフォーマンスが大幅に低下したことを説明したと指摘しました。 コメント ↗
- 技術的な指摘: あるコメンターは、この問題が特定のマザーボードのファームウェアの制限に起因していることを明らかにしました。BIOSがPCIデバイスの利用可能なアドレス空間を制限するため、大きなBARが重複し、利用可能なスロットを超えてしまうというものです。 コメント ↗
- 懐疑的: 複数のコメンターは、ソフトウェアレイヤーや隠れた設定によってハードウェアが物理的な能力をフルに活用できないことに不満を表明し、なぜこれほど大きな仮想アドレス空間がより簡単に管理できないのか疑問を呈しました。 コメント ↗
Hacker Newsのスレッドで出た意見の要約です。事実として検証されたものではありません。 議論の全文を読む ↗