x86_64上のLinuxは、メモリマップドIOによってマスクされた「失われた」物理メモリをどのように回復しますか？
/proc/iomemは、重要なアドレス空間が私のボックスのビデオカードなどのPCIデバイスにマップされていることを示します。e0000000-efffffff : 0000:01:00.0私の計算が正しければ、これは250MBです。 16GBしかない64ビットデスクトップRAM Linuxまたはすべての最新のカーネルが物理メモリのその部分を回復するためにできるトリックがあると思いますが、正確にはどのくらいですか？
やや関連する質問-ノースブリッジ/メモリコントローラーがプログラム可能なルールに基づいてメモリ/ ioアクセスをルーティングする場合、メモリマップド領域（たとえば、pciデバイス）への書き込みアクセスの場合、RAMそれらがルーティングされるため、それらの書き込みについてさえ知らない場合は、ある種の「ルーティングテーブル」があるはずですか？そして、そのようなテーブルはどこにありますか？Linuxカーネルはこのテーブルにどのようにアクセスしますか？
64ビットオペレーティングシステムを使用しているため、BIOS設定「Above4G Decoding」、「64ビットI/Oアドレスデコード」、またはシステム/マザーボードベンダーから呼び出されたものを有効にすることができます。この設定を有効にすると、64ビットアドレスを処理できるすべてのMMIOハードウェアが、従来の32ビット範囲外のアドレスにマップされ、メモリとの競合が最小限に抑えられるため、スロットを再マップする必要が少なくなります。
私のシステムでは、GPUの結果のマッピングは次のようになります。
6000000000-600fffffff : 0000:01:00.0
また、250MBは16 GBの約1.5％です。メモリの最後の1.5％を取得することが本当に重要な場合は、可能であれば、より多くのRAMを取得することで、パフォーマンスが大幅に向上する可能性があります。
私の知る限り、メモリ再マッピングの「ルーティングテーブル」は、少なくとも部分的にチップセットハードウェアに実装されており、非常にチップセット固有であるため、通常、システムファームウェアによって起動時に設定されます。実行時アクセスが可能な場合は、ACPIファームウェアルーチンを介してアクセスすることを期待します。そうしないと、カーネルにチップセットごとに特定のルーチンが必要になります。
（はい、カーネルには既知のハードウェアバグを回避するためのハードウェアモデル固有の癖ルーチンがありますが、それよりも深くなり、システムファームウェアによって提供されるACPI抽象化をバイパスするには、 coreboot 。）
このトピックに関連するいくつかのwikiページがあることがわかりました： PCI_hole および _GB_barrier
現在、x86では、PCIホールはメモリの再マッピングを介して処理できますが、これは、16M未満の複数の小さな領域など、MMIOによって盗まれたすべてのRAMアドレスを回復しません-チップセットには、制限された再マッピング機能しかありません地域の数。