The project exposes Nvidia VRAM as a block device and lets Linux use it as swap. The author built it for a hybrid-graphics laptop where the discrete Nvidia GPU and its VRAM were mostly idle, while the soldered system RAM was the real bottleneck. That framing mattered. People did not treat this as a general memory upgrade. They treated it as a practical hack for machines with fixed RAM, spare VRAM, and workloads that are bursty enough that you can reclaim the swap before launching a game, local model, or GPU job.
Idle GPU memory can be repurposed for niche memory pressure problems, but today’s Linux and driver stack make it more of an interesting workaround than a credible replacement for RAM, NVMe swap, or forthcoming coherent memory standards like CXL.
Curious and positive about the hack itself, but skeptical that it is broadly useful in its current form because the software path is slow, the operational edge cases are nasty, and normal NVMe or zram setups are often good enough.
01 The disappointing benchmark is mostly a software architecture problem, not a verdict on VRAM.
Routing swap through NBD, user space, CUDA, and bounce buffers turns simple page traffic into a storm of copies and wakeups, while Linux swap internals add their own ceiling through page unmapping and TLB shootdowns. Even a cleaner driver would still run into kernel memory-management limits before getting close to PCIe or GDDR bandwidth.
The hardware is not the real bottleneck here. Linux swap and the chosen I/O path are.
02 Consumer VRAM is not just "more RAM on another bus.
" Without cache coherency, the CPU cannot safely treat GPU memory like normal system memory, which is why this has to be swap or another explicitly managed tier. CXL is the missing piece for real memory expansion over PCIe-style links, not a faster PCIe generation or a kernel toggle.
VRAM can be a storage tier. It cannot be transparent main memory on ordinary consumer hardware.
03 The viable use case is narrower and cleaner than the headline suggests.
This works when GPU-heavy and memory-heavy workloads do not overlap, and when you can `swapoff` the VRAM device before starting a game or local model. That makes it a tactical pressure valve for fixed-RAM machines, not a permanently enabled feature.
This only makes sense when your idle GPU and your memory-hungry apps take turns.
04 The operational risk is not just speed.
Keeping swap in VRAM can interfere with desktop graphics allocation and keep the discrete GPU from fully idling, which means possible Wayland crashes under VRAM pressure and worse battery life on laptops. The cost of "using idle VRAM" is that the GPU may stop being meaningfully idle.
VRAM swap competes with graphics stability and power management. That tradeoff is easy to ignore until it bites you.
01 Avoiding SSD wear is one of the few clean arguments for this project.
If a machine does swap regularly, moving some of that churn off NAND and onto VRAM removes write-cycle concerns entirely. That benefit is real even if the performance case is mixed.
If flash endurance is your pain point, VRAM swap solves a problem NVMe never will.
02 SSD wear is usually overstated for mainstream use.
One commenter reported a decade-old heavily swapped laptop SSD that still looks healthy, while another pointed out that niche workflows like Gentoo builds can absolutely create enough churn for endurance to matter. The better reading is that wear is workload-specific, not a universal reason to prefer VRAM.
Flash wear is not fake, but it is also not a blanket justification for this hack.
03 Treating GPU memory as a first-class managed resource in the kernel is not obviously absurd.
The current project is a hack because the platform does not expose VRAM as coherent memory, but the broader instinct is sound. Operating systems increasingly need to manage multiple memory tiers, and accelerators are part of that future.
The implementation is niche today. The resource-management idea is bigger than this project.