The nbd-vram daemon got a thread pool, ~4x concurrent 4K IOPS, and the swap-pressure freeze is finally gone.

Fresh benchmarks against NVMe included:

https://www.seanlobjoit.com/posts/2026-06-12-vram-swap-two-w...

Insightful take, looking into these

Thank you for pointing me to this

Thanks for sharing this, good read :-)

This was a consideration when I wrote this

I am catching up on comments

The reason I wrote this is I run this laptop in hybrid (AMD display + NVIDIA as swap). So all at VRAM was going to waste.

On your question re: switchable swap. It's on my to-do list ;)

Wouldn't this prevent the nvidia GPU from being power gated since it's never "idle"? So like your battery life regresses?

While it may prevent sleep, one of the frustrations I have on an old skylake desktop with a bunch of 1080ti GPUs is that when set to power saving modes, the GPUs sit at 1x2.0 pcie lanes and low wattage. That slows down loading quite a bit.

So it will use more power, but nothing close to when the GPU is being used.

Is VRAM not directly accessible by the system then? Since it's mapped directly into the CPU's address space, I had assumed that there's a simple DMA controller managing said access and I would then also naively assume that said controller is separate (or at least on a separate power plane) from the actual GPU.

they are talking about the scenario of having a discreet GPU in addition to the GPU on the CPU. So there's 2 GPUs, and the nvidia one has its own VRAM (typically of the GDDR variety even) that isn't shared with system RAM (hence the purpose of this project). So that also means 2 memory controllers.

Good point, you might wanna disable it on battery, but I'm guessing a lot of people have their laptop plugged in practically 24x7.