The 8.5 GB that showed up as free¶
The fix in the last post was two more matching 32 GB sticks, and the sticks arrived. Four slots filled, all four the same part number, negotiated speed 4800 MT/s at 2DPC — right in the predicted range. With 128 GB installed I figured the GPU VM could take 114 and still leave the host its 2 GB. The host OOM'd.
Dropped it to 110 and it's been stable since, but the math didn't add up and I couldn't let that sit. MemTotal is 125.2 GiB. VM takes 114, Proxmox "needs 2", that leaves nine spare. Why did it die?
Reading the autopsy instead of guessing¶
The kernel prints a full memory census at the moment it invokes the OOM killer, and this one was sitting in dmesg:
Nine point three GiB free — of which eight point nine was in the CMA region, and the allocation that was failing wouldn't take those pages. Effective free memory at the moment of death: about 0.3 GiB. That's the whole story of the OOM.
The confusing part is that /proc/meminfo still says CmaTotal: 0 kB, which is exactly what I measured in the last post. That number is misleading. The zone info tells the truth:
plus 2.1 million pages in vmstat — about 8.5 GiB sitting in MIGRATE_CMA pageblocks. CMA is the Contiguous Memory Allocator: physically contiguous RAM held for device DMA. On this box it belongs to the integrated Intel GPU. i915 is loaded, the iGPU is enabled in BIOS, and it has never done anything — the box is headless and the 5090 does all the display work. It still gets a parking lot, and every memory counter in the box counts that parking lot as free.
The real landlord¶
Once I stopped trusting the headline numbers, the host reservation on this machine turned out to be three floors, not one:
- ~2.8 GiB firmware/MMIO. The BIOS e820 map has a 1.4 GiB hole below 4 GB — that's PCIe MMIO address space, because the 5090's BARs have to be addressable — plus kernel bookkeeping. BIOS-level, identical on any OS.
- ~8.5 GiB CMA pool for the iGPU that never gets used.
- ~3–4 GiB host kernel, Proxmox services, and the QEMU process.
About 15 GiB, not 2. And the census confirmed the other half of the equation: all 114 GiB of the guest showed up as inactive_anon on the host. The guest's page cache is host anon memory — a "mostly idle" guest still gets charged one-to-one, because Linux fills every free GB with cache and the host can't see inside it.
Now the math balances:
114 (guest, fully touched) + 8.5 (CMA) + ~4 (host) ≈ 126.5 > 125.2 -> OOM
110 + 8.5 + 4 ≈ 122.5 < 125.2 -> stable, 13 GiB spare
The lever¶
Disabling the integrated graphics in BIOS should make most of that 8.5 GiB pool evaporate — the box is headless, the 5090 handles display. Haven't done it yet, but it's the one honest way to claw the memory back. The MMIO holes are just how the bus works.
The thought experiment that made this click: these reservations are fixed-size, not proportional. Eleven GiB on a 128 GB box is a rounding error. On a 16 GB box it's 17% of the machine. That's why small-RAM passthrough builds are a trap — the tax doesn't care how poor you are.
The corrected sizing rule and the current numbers live on the Proxmox page.