512MB（x86）システムで82MBの「予約済みメモリ」

Question

SWIOTLBがシステムでアクティブになっています。 64M RAMはデフォルトで予約されています。 4G以上のRAMがあり、ハードウェアIOMMUが利用できない場合、またはネストされたページテーブルなしでXen仮想化で実行されている場合にのみ必要です。おめでとうございます。カーネルでバグが見つかりました:-).

次の起動オプションのいずれかが正しく機能します。

iommu=off- SWIOTLBを無効にします。
swiotlb=1- SWIOTLBを「スラブ」= 128Kに減らします。

あるいは、カーネルソースコードにパッチを当てることもできます。以下のパッチと修正されたバグの説明を参照してください。 :-).

問題分析

[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000dffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable

実際のRAMのマッピング範囲は0〜512Mです。私たちは一般的なレガシーごみから始めますが、これは100万（0x100000）未満の領域にのみ影響します。

[    0.113219] RAMDISK: [mem 0x1e40a000-0x1f885fff]

初期のRAMディスクは約20M程度を占めています。

[ 0.648160] Memory: 419336K/523896K available (6751K kernel code, 660K rwdata, 2068K rodata, 880K init, 452K bss, 104560K reserved, 0K cma-reserved, 0K highmem)

しかし今、私たちは104Mを予約しました。これには後でリリースされるinitrdも含まれていると思います。

[    6.074902] Freeing initrd memory: 20976K

私の考えのほとんどのダメージはここにあります。

[    6.074945] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    6.074962] software IO TLB: mapped [mem 0x16000000-0x1a000000] (64MB)

64Mは基本サイズバウンスバッファに割り当てられます。

swiotlbは、すべてのシステムメモリにアクセスできない[DMA]デバイスで使用するためのバウンスバッファリングメカニズムです。

swiotlbコードは、ブートプロセスの最初に低メモリの大きな塊を割り当て、次にDMA割り当て要求に応答してそのメモリを割り当てます。ほとんどの場合、swiotlbメモリの使用には、ドライババッファとデバイスにアクセスできるswiotlbスペースの間にデータがコピーされる「バウンスバッファ」の作成が含まれます。 swiotlbで使用されるメモリは通常のLinuxメモリ管理メカニズムから削除されているため、DMAバッファ以外の目的にはアクセスできません。このため、swiotlbはせいぜいエレガントではないと考えられています。

DMA質問、パート2、LWN.net、2004。

この説明で奇妙なことは、swiotlbがもともとIntelによって実装された解決策だったことです。x86-64。 x86-32 Linuxの現在破損している状態に違反しているようです。 Linuxが多くのx86-32およびx86-64コードを「統合」するときに間違いでしょうか？

これSWIOTLB初期化コードつまり、4GB以下のシステムでは活性化してはいけないという意味なのに…破損しているようです。

/* 4GB broken PCI/AGP hardware bus master zone */
#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)

...

 * If 4GB or more detected (and iommu=off not set) or if SME is active
 * then set swiotlb to 1 and return 1.
 */
int __init pci_swiotlb_detect_4gb(void)
{
    /* don't initialize swiotlb if iommu=off (no_iommu=1) */
    if (!no_iommu && max_possible_pfn > MAX_DMA32_PFN)
        swiotlb = 1;

32ビット用にビルドすると、問題は4UL * 1024 * 1024 * 1024-Dと評価されます。0

修正は次のようにする必要があります

arch/x86/include/asm/dma.h:
-#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)
+#define MAX_DMA32_PFN (4UL * ((1024 * 1024 * 1024) >> PAGE_SHIFT)))

私はこのカーネルパッチをGPL2に従ってリリースしました（パブリックドメインにも含まれています）。テストまたは提出する予定はありません。この知識を使って、必要なことを行います。

Answer 1

SWIOTLBがシステムでアクティブになっています。 64M RAMはデフォルトで予約されています。 4G以上のRAMがあり、ハードウェアIOMMUが利用できない場合、またはネストされたページテーブルなしでXen仮想化で実行されている場合にのみ必要です。おめでとうございます。カーネルでバグが見つかりました:-).

次の起動オプションのいずれかが正しく機能します。

iommu=off- SWIOTLBを無効にします。
swiotlb=1- SWIOTLBを「スラブ」= 128Kに減らします。

あるいは、カーネルソースコードにパッチを当てることもできます。以下のパッチと修正されたバグの説明を参照してください。 :-).

問題分析

[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000dffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable

実際のRAMのマッピング範囲は0〜512Mです。私たちは一般的なレガシーごみから始めますが、これは100万（0x100000）未満の領域にのみ影響します。

[    0.113219] RAMDISK: [mem 0x1e40a000-0x1f885fff]

初期のRAMディスクは約20M程度を占めています。

[ 0.648160] Memory: 419336K/523896K available (6751K kernel code, 660K rwdata, 2068K rodata, 880K init, 452K bss, 104560K reserved, 0K cma-reserved, 0K highmem)

しかし今、私たちは104Mを予約しました。これには後でリリースされるinitrdも含まれていると思います。

[    6.074902] Freeing initrd memory: 20976K

私の考えのほとんどのダメージはここにあります。

[    6.074945] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    6.074962] software IO TLB: mapped [mem 0x16000000-0x1a000000] (64MB)

64Mは基本サイズバウンスバッファに割り当てられます。

swiotlbは、すべてのシステムメモリにアクセスできない[DMA]デバイスで使用するためのバウンスバッファリングメカニズムです。

swiotlbコードは、ブートプロセスの最初に低メモリの大きな塊を割り当て、次にDMA割り当て要求に応答してそのメモリを割り当てます。ほとんどの場合、swiotlbメモリの使用には、ドライババッファとデバイスにアクセスできるswiotlbスペースの間にデータがコピーされる「バウンスバッファ」の作成が含まれます。 swiotlbで使用されるメモリは通常のLinuxメモリ管理メカニズムから削除されているため、DMAバッファ以外の目的にはアクセスできません。このため、swiotlbはせいぜいエレガントではないと考えられています。

DMA質問、パート2、LWN.net、2004。

この説明で奇妙なことは、swiotlbがもともとIntelによって実装された解決策だったことです。x86-64。 x86-32 Linuxの現在破損している状態に違反しているようです。 Linuxが多くのx86-32およびx86-64コードを「統合」するときに間違いでしょうか？

これSWIOTLB初期化コードつまり、4GB以下のシステムでは活性化してはいけないという意味なのに…破損しているようです。

/* 4GB broken PCI/AGP hardware bus master zone */
#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)

...

 * If 4GB or more detected (and iommu=off not set) or if SME is active
 * then set swiotlb to 1 and return 1.
 */
int __init pci_swiotlb_detect_4gb(void)
{
    /* don't initialize swiotlb if iommu=off (no_iommu=1) */
    if (!no_iommu && max_possible_pfn > MAX_DMA32_PFN)
        swiotlb = 1;

32ビット用にビルドすると、問題は4UL * 1024 * 1024 * 1024-Dと評価されます。0

修正は次のようにする必要があります

arch/x86/include/asm/dma.h:
-#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)
+#define MAX_DMA32_PFN (4UL * ((1024 * 1024 * 1024) >> PAGE_SHIFT)))

私はこのカーネルパッチをGPL2に従ってリリースしました（パブリックドメインにも含まれています）。テストまたは提出する予定はありません。この知識を使って、必要なことを行います。

512MB（x86）システムで82MBの「予約済みメモリ」

答え1

問題分析

関連情報