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 ↩
Compute Unified Device Architecture, Nvidia’s proprietary software platform for programming and accelerating work on Nvidia GPUs.
CXL ↩
Compute Express Link, a hardware interconnect standard meant to let processors and accelerators share memory and devices more efficiently.
DRAM ↩
Dynamic Random-Access Memory, a common type of computer memory used in servers and other hardware.
GDDR ↩
Graphics Double Data Rate memory is a memory type designed for graphics cards and other devices that need high-speed graphics data access.
LLM ↩
Large Language Model, a machine learning model trained to generate and analyze human-like text.
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 high-speed storage interface commonly used for solid-state drives.
OpenCL ↩
Open Computing Language, an open standard for writing programs that run across different kinds of accelerators such as graphics processing units.
PCIe ↩
Peripheral Component Interconnect Express, the high-speed internal bus used to connect devices like network cards 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 storage device that uses flash memory instead of spinning disks.
TLB ↩
Translation Lookaside Buffer, a small CPU cache that stores recent virtual-memory address translations.
VRAM ↩
Video random-access memory, the memory attached to a graphics processor.
Wayland ↩
A modern Linux display protocol that replaces parts of the older X11 graphics system and supports tighter security boundaries.

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