The editorial argues the hack's real value isn't swap speed but what it reveals: modern workstations have a 900 GB/s VRAM pool sitting at 2% utilization while the kernel thrashes 1 GB/s NVMe random I/O. The OS's swap subsystem is blind to the second-fastest memory pool in the machine, accessible only through a graphics API designed for triangle rasterization.
The project author built nbd-vram on the premise that idle GPU VRAM on workstations is wasted capacity that could serve as a vastly faster swap target than NVMe. The 252-point HN score and reproduced benchmarks validate the core claim that 4K random I/O to VRAM beats Gen5 SSDs by an order of magnitude.
The editorial points out the comedic Rube Goldberg path each page takes: kernel page fault → NBD client → loopback TCP → userspace NBD server → CUDA runtime → PCIe DMA → VRAM, with four context switches and a TCP handshake involved in what is fundamentally a memory-to-memory copy. The 'this is cursed' reaction from HN commenters captures the legitimate concern that the architecture is fighting the hardware rather than working with it.
A project called `nbd-vram`, posted to Hacker News and climbing to 252 points, does exactly what the name says: it exposes a chunk of NVIDIA GPU VRAM as a Network Block Device on Linux, then lets you `mkswap` and `swapon` it like any other block device. The whole thing is small — a userspace NBD server that allocates a CUDA buffer, handles read/write requests by `cudaMemcpy`-ing between host pages and device memory, and lets the kernel treat the result as a 16GB (or however much you allocate) swap partition.
The premise is that modern workstations routinely ship with 24GB of GPU memory that sits at 2% utilization while the CPU thrashes its 32GB of DDR5 into NVMe swap. If you're not training models or rendering, that VRAM is dead weight. The author's pitch: reclaim it. Point swap at the GPU instead of the SSD, and page-outs land in a memory pool that's an order of magnitude faster than even a Gen5 NVMe drive on random 4K I/O — at least on paper.
The top HN comments oscillate between "this is brilliant" and "this is cursed." Both are correct.
The interesting thing isn't the swap speed. It's what the hack reveals about the absurdity of the modern memory hierarchy. A workstation has DRAM at ~80 GB/s, VRAM at ~900 GB/s sitting one PCIe hop away, and NVMe at ~7 GB/s sequential / ~1 GB/s random. The kernel's swap subsystem only knows about the slowest one. We've built systems where the second-fastest pool of memory in the machine is invisible to the OS, accessible only through a graphics API designed for triangle rasterization.
The path a swapped-out page now takes is genuinely funny: kernel page fault → NBD client → loopback TCP → userspace NBD server → CUDA runtime → PCIe DMA → VRAM. Then back the same way on fault-in. There are at least four context switches and a TCP handshake involved in what is, at the hardware level, a memory-to-memory copy. And yet benchmarks in the repo and reproduced by HN commenters show 4K random read latencies in the 30–60μs range — roughly 2-3× faster than a Samsung 990 Pro on the same machine. The userspace overhead is real, but PCIe 4.0 x16 at ~32 GB/s still wins against any SSD on the bus.
The comparison to existing tricks is illuminating. zswap and zram compress pages into DRAM, which is faster still but consumes the same memory you're trying to free. Intel's old Optane DIMMs put NVDIMM-scale memory on the memory bus and Intel killed the product line in 2022. CXL memory pooling is the "real" answer to tiered memory but requires a $5,000 motherboard and a server CPU. A consumer-grade GPU you already own, sitting idle 22 hours a day, is in some sense the most accessible Tier-2 memory device in existence — we just never thought to use it that way.
The community reactions are worth reading. One thread argues this is essentially what unified memory architectures (Apple Silicon, AMD APUs) already do at the hardware level, and the hack is reinventing UMA poorly via NBD. Another points out that NVIDIA Grace Hopper exposes the GPU's HBM as a coherent NUMA node — which is true but costs $40K. A third notes that you could probably do the same trick with `dm-target` or a custom `bdev` driver and skip the NBD/TCP round-trip entirely, dropping latency another 10-20μs. The author acknowledges this and says NBD was chosen for prototyping speed, not performance.
Probably nothing, today. The hack collapses the moment you launch a CUDA workload — your swap device gets evicted or corrupted depending on how aggressively the driver reclaims memory. If you actually use your GPU for ML, gaming, or compute, this is unsafe. The author is clear about this. There's no isolation, no priority, no fallback. It's a toy.
But the underlying idea is not a toy, and the people who should be paying attention are kernel folks and distro maintainers. The kernel already has the abstractions — `zswap` writeback targets, `pmem` devices, `dax` — to make tiered memory a first-class concept. What's missing is a clean way to register "I have N gigabytes of fast-ish memory at this address, please use it as a backing store with these eviction semantics" without going through a graphics API or a block device emulator. If GPU vendors exposed an MMIO BAR for non-compute memory use, with a simple priority/preemption model, the OS could integrate it natively. NVIDIA's own GPUDirect Storage is close but pointed in the opposite direction (NVMe → GPU, not GPU → host swap).
For most developers, the practical takeaway is more philosophical: when you next look at your system and see 24GB of VRAM at 2% utilization, remember that you are looking at a resource you have no good way to use. That gap — between what your hardware can do and what your OS will let it do — is where most of the next decade of systems work lives. Memory tiering, heterogeneous compute, CXL, accelerator-side caching: it's all variations on the same theme.
Expect more of this. The economics of consumer GPUs have made 16-24GB VRAM standard, and the AI boom has accelerated the trend — a 32GB consumer card is a year or two away. Meanwhile, DRAM scaling is dead, NVMe latency is bounded by NAND physics, and CXL adoption outside the datacenter is glacial. The arbitrage opportunity between "memory we have" and "memory the OS can use" is going to keep growing until someone — kernel, GPU vendor, or another c0dejedi — builds the boring, production-grade version of this hack. Until then, `nbd-vram` is the most interesting 200 lines of C you'll read this month, even if you'd never run it on a machine you cared about.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.