HN Debrief

Use your Nvidia GPU's VRAM as swap space on Linux

  • Infrastructure
  • Hardware
  • Open Source
  • Linux

The project exposes Nvidia VRAM as a block device over Linux NBD so the kernel can use it as swap. The target case is not "replace RAM with GPU memory". It is "my laptop has soldered RAM, an idle discrete Nvidia GPU, and I would rather spill cold pages into VRAM than hammer an SSD." That framing held up. People with hybrid-graphics laptops, gaming rigs, or dev boxes with large idle GPUs saw the appeal. Nobody treated it like a real substitute for system RAM because consumer VRAM sits behind PCIe and outside the CPU's cache-coherent memory system.

Treat this as a clever niche workaround, not a general memory upgrade. If you care about making it practical, the bottleneck is Linux swap and driver plumbing, not raw PCIe or VRAM bandwidth, and you need a clean way to disable it under GPU pressure or on battery.

Discussion mood

Mostly amused and positive. People liked the ingenuity and saw a real niche for fixed-RAM laptops or idle secondary GPUs, but the dominant reaction was that the current version is bottlenecked by software overhead and needs safeguards around power use, VRAM pressure, and desktop stability before it is more than a fun hack.

Key insights

  1. 01

    Linux swap plumbing is the real bottleneck

    The poor throughput is coming from the path, not the bus. NBD in userspace adds wakeups, copies, and per-page overhead, and even a cleaner design still runs into Linux memory-management costs like page unmapping and TLB shootdowns. That means a custom driver alone would help, but it still would not unlock anything close to raw PCIe or GDDR numbers without deeper kernel changes.

    Do not evaluate this idea by comparing 1.3 GB/s to theoretical GPU bandwidth. If you want to productize it, focus on kernel integration and swap-path changes before chasing CUDA or PCIe micro-optimizations.

      Attribution:
    • Teknoman117 #1
    • lstodd #1
    • tumblestick #1
  2. 02

    VRAM pressure can break the desktop

    Using VRAM as swap works only while that VRAM stays genuinely spare. A game, CUDA job, local LLM, or even dynamic Wayland allocations can suddenly need that memory, and commenters called out ugly failure modes ranging from desktop crashes to swap disappearing under a new GPU process. The idea needs policy, not just plumbing.

    If you try this on a workstation or laptop, build an escape hatch first. You want fast swapoff, VRAM pressure monitoring, and a battery-aware disable path before trusting it on your daily machine.

      Attribution:
    • kllrnohj #1
    • nyrikki #1
    • qingcharles #1
    • drdaeman #1
    • AI2070 #1
  3. 03

    Consumer VRAM is not just extra system RAM

    The hardware model is the limiting fact here. Typical GPU memory on consumer cards is outside the CPU's cache-coherent domain, so even if resizable BAR lets you map it, CPU access is uncached or weakly cached and painfully slow. Commenters pointed to CXL and IBM CAPI as examples of the kind of coherency support you need before memory on an expansion device starts behaving like normal RAM.

    Use swap as the mental model, not memory expansion. If your roadmap depends on GPUs contributing to the host's main memory pool, you are really talking about coherent interconnects like CXL, not a software trick.

      Attribution:
    • Tuna-Fish #1 #2
    • tiberious726 #1
    • Teknoman117 #1
  4. 04

    This fits non-overlapping GPU and CPU workloads

    The workable use case is a machine where the discrete GPU is mostly idle during memory-heavy work, then reclaimed before gaming or local AI starts. Linux can offline a swap device with swapoff if there is somewhere else for those pages to go, so VRAM swap does not have to be permanent. That makes hybrid-graphics laptops a much better fit than desktops that constantly bounce between desktop compositing, CUDA, and games.

    This is most plausible on systems with predictable mode switches. If your users alternate between coding and gaming or between office work and local inference, you can wire this into those transitions instead of leaving it on all day.

      Attribution:
    • Saris #1
    • eru #1
    • nuccy #1
    • c0dejedi #1
  5. 05

    SSD wear is a weak but real argument

    Avoiding NAND wear was one stated motivation, but commenters narrowed it sharply. For most modern SSDs, ordinary swap traffic is unlikely to be the decisive lifetime problem, especially on large drives. The exception is sustained swap-heavy workflows on small drives, such as memory-hungry source builds on Gentoo, where churn can be more than theoretical.

    Do not oversell flash endurance as the main reason to do this. It matters only in a narrow class of write-heavy, RAM-starved workloads, so measure your actual swap write volume first.

      Attribution:
    • dannyw #1
    • markhahn #1
    • LtdJorge #1
  6. 06

    The idea is old, the packaging is new

    People surfaced several predecessors: Arch Linux's old video-RAM swap guidance, Overv's vramfs, libguestfs nbdkit-vram-plugin using OpenCL, and Windows GPU RAM drive experiments. That changes the read on this repo. It is not a brand-new systems idea. It is a current Nvidia-and-Linux implementation of a long-running hack that keeps resurfacing because the niche keeps existing.

    If you want to build on this, read the earlier projects before reinventing the same tradeoffs. They already explored compatibility, FUSE and loop overhead, and AMD or OpenCL paths.

      Attribution:
    • kimixa #1
    • rwmj #1
    • molticrystal #1
    • theblazehen #1

Against the grain

  1. 01

    NVMe may still beat this today

    The headline promise is "VRAM is faster than disk," but the posted benchmark does not cash that out. One commenter noted that this implementation's sequential throughput is low enough that a good NVMe swap path can actually move data faster, even if latency differs. That punctures the intuitive case for VRAM swap in its current form.

    Benchmark against your actual SSD before assuming this helps. On a modern laptop, the existing NVMe swap path may already be the better engineering choice.

      Attribution:
    • RachelF #1
  2. 02

    Many modern systems do not need swap much

    Several comments rejected the premise that desktop Linux boxes with 16 GB to 64 GB RAM are hitting swap in ordinary use. For that audience, the project solves a problem they rarely see outside suspend-to-disk or pathological workloads, which makes the complexity hard to justify.

    Start from your memory pressure, not from spare VRAM. If your machines almost never swap, this is an interesting hack and little more.

      Attribution:
    • dlt713705 #1 #2
    • xxs #1

In plain english

CAPI ↩
Coherent Accelerator Processor Interface, an IBM technology for attaching accelerators with cache-coherent access to system memory.
CUDA ↩
NVIDIA’s platform for running general-purpose computing code on graphics processing units.
CXL ↩
Compute Express Link, a high-speed interconnect standard that lets devices share memory with cache coherence over links related to PCI Express.
DRAM ↩
Dynamic Random Access Memory, the common type of volatile memory used as main system memory in servers and PCs.
GDDR ↩
Graphics Double Data Rate memory, a memory type commonly used in graphics cards.
LLM ↩
Large language model, an artificial intelligence system trained on large text datasets to generate and analyze language.
NBD ↩
Network Block Device, a protocol that exposes remote storage blocks to a client as if they were a local disk.
NVMe ↩
Non-Volatile Memory Express, a storage protocol used by fast solid-state drives connected over PCI Express.
OpenCL ↩
Open Computing Language, a framework for writing code that runs across GPUs and other accelerators.
PCIe ↩
Peripheral Component Interconnect Express, the main high-speed expansion bus used to connect GPUs, SSDs, and other devices to a computer.
Resizable BAR ↩
A PCIe feature that lets the CPU map a larger portion of a GPU's memory at once instead of a small fixed window.
SSD ↩
Solid-state drive, a flash-based storage device that is much faster than a hard disk drive for most desktop workloads.
TLB ↩
Translation Lookaside Buffer, a CPU cache that speeds up virtual memory address translation.
VRAM ↩
Video RAM, memory attached to a GPU and used for graphics or AI model computation.
Wayland ↩
A modern display server protocol used on Linux desktops.

Reference links

Prior art and related projects

  • Arch Linux wiki: Swap on video RAM
    Older documentation showing that Linux users have experimented with VRAM-backed swap before.
  • Overv vramfs
    Earlier OpenCL and FUSE-based approach to exposing VRAM as storage, cited as prior art and a compatibility reference.
  • libguestfs nbdkit-vram-plugin
    OpenCL-based VRAM-backed block device plugin that can work on AMD hardware.
  • GpuRamDrive
    Windows proof-of-concept RAM drive backed by GPU memory, mentioned as a similar experiment.
  • GpuRamDrive AMD fork
    Fork of the Windows GPU RAM drive project with AMD support.
  • theblazehen vramblk
    Another implementation of VRAM-backed swap or block storage using OpenCL, offered with a caution that performance still feels like normal swapping.

Kernel and systems references

GPU storage and interconnect

Background discussion and misc