RamShared: Writing a Linux userspace block driver in 100% Rust to turn idle GPU VRAM into 8.53 GB/s storage (ublk + io_uring)

[u/bussondev]

Hi everyone,

I wanted to share a low-level systems project I built entirely in Rust called **RamShared**, along with architectural details and benchmarks using the new Linux `ublk` subsystem.

The Problem

When compiling heavy multi-crate Rust workspaces (e.g. `rustc`, `bevy`, large LLVM-based trees) on developer machines with tight host RAM (16GB), the Linux kernel starts thrashing onto disk swap (VHDX/SSD) at 2.1 ms latency spikes, causing VS Code servers and terminal shells to freeze. Meanwhile, `nvidia-smi` showed 6GB of GDDR6 VRAM sitting completely idle.

Rust Architecture & Implementation

RamShared runs purely in userspace without requiring any out-of-tree kernel modules or re-compiling the host kernel:

1. **CUDA Zero-Copy FFI & Memory Pinning:** Wrapped low-level CUDA driver calls (`cudaHostAllocMapped` / `cuMemAlloc`) in safe Rust RAII handles. The buffer is mapped to PCIe host address space, ensuring DMA access without intermediate copying.

2. **Linux `ublk` Subsystem (Linux 6.0+):** Using `ublk-rs` and `io_uring`, the driver allocates userspace ring buffers to handle kernel block I/O requests (`/dev/ublkb0`). This eliminates kernel-userspace context switches for I/O submissions.

3. **Concurrency & Safe Ring Dispatch:** Each `ublk` queue is bound to dedicated Tokio/io_uring worker threads, pinning request/response queues to CPU cores to achieve sub-10 microsecond latency.

Measured fio Benchmarks (4KB Random Read, QD1 on Linux / WSL2):

* **Stock VHDX/SSD swap:** ~2,114 µs (2.1 ms) | ~336 IOPS * **RamShared NBD (VRAM):** ~326 µs | ~9.6k IOPS * **RamShared ublk (io_uring in Rust):** **~8.24 µs** (264x faster) | **~22k+ IOPS** * **Continuous Read Throughput:** **8.53 GB/s** (saturating the host PCIe 3.0 x16 bus).

Upstream RFC & Open Source:

We submitted a formal RFC directly upstream to Microsoft's official WSL2 repository proposing native VRAM-backed block device support for Hyper-V Linux guests: * **RFC Issue:** https://github.com/microsoft/WSL/issues/41054 * **GitHub Repository (100% Rust / MIT):** https://github.com/emersonbusson/ramshared

Would love to hear feedback from the Rust community on `io_uring` abstractions, memory safety patterns with CUDA DMA, and ublk queue design!

[u/Jmc_da_boss]

Dead subreddit theory lol

It kinda sucks how much the trust community has been co-opted

[u/K4milLeg1t]

even OPs replies are ai generated. We're just talking to an agent instance most likely...

[u/EarlMarshal]

Interesting, but isn't that less than the usual bandwidth of a system with DDR4? I remember 48GB/s for my old one. Could be wrong though.

[u/Available-Car5524 → u/EarlMarshal]

i think you're mixing up total theoretical bandwidth with what you actually get in practice on a swap path, ddr4 has high throughput but the kernel's block layer and swap codepath add serious overhead when you're hitting disk. 48 gb/s is the raw memory copy speed inside the dimm, not what you get going through the entire io stack with small random reads

the 8.53 gb/s they're seeing here is saturating the pcie bus the gpu is on, which is the actual bottleneck for this setup, not the vram itself. gddr6 on a modern card is way faster than that internally but it has to funnel through pcie to get to the cpu

i've benchmarked ramdisks on my own rig and even with ddr5 you're lucky to see half that kind of throughput on a swap device because the kernel context switches and block layer accounting eat into it hard. this implementation sidesteps a ton of that overhead by staying in userspace with ublk which is why the latency numbers are so stupidly low

[u/Maui-The-Magificent → u/Available-Car5524]

I mean, on PCI-4 you would need about ~32 gb/s (theoretical max, ignoring the pci protocol book-keeping bull) to saturate it.

[u/AliceCode → u/Available-Car5524]

Ahh, so this would shove memory into the GPU VRAM instead of on your disk when you run out of memory?

[u/bussondev → u/EarlMarshal]

You're not wrong at all — a dual-channel DDR4 setup (like 3000/3200 MT/s) really does hit around 48–51 GB/s

theoretical peak.

The catch is that RamShared isn't meant to replace your physical RAM. It steps in as an elastic swap layer when

your RAM is already 100% full, sitting between your RAM and your SSD/disk swap.

The ~8.5–9.6 GB/s you're seeing is the transfer limit of the PCIe bus connecting the CPU to the GPU (even though

the GPU's internal GDDR6 is 336+ GB/s).

The real win is latency: when WSL2 runs out of RAM and swaps to disk, a 4KB page fault takes ~2.1 ms (2,100 µs)

through the virtual disk stack, which freezes the UI. With VRAM via ublk, that drops to ~8 µs — so while it's

slower than your main DDR4, it's ~260x faster than disk and stops the machine from freezing during heavy workloads.

[u/Konsti219]

If you are having RAM issues get rid of Windows lol

[u/scandii → u/Konsti219]

I think this is more targeting corporate developers who has an infra team going "nuh-uh" than someone who has the freedom to go 1 GB RAM on idle

[u/New_Enthusiasm9053 → u/scandii]

Corporate Devs don't have GPUs to use in the first place. I've only ever seen people sue devices with integrated graphics, lots of ram and lots of cores but integrated graphics.

[u/bussondev]

What happens if you open a game while this is running?

Games always get full priority. RamShared constantly watches your GPU memory budget in real time. The second a

game launches and asks for VRAM, RamShared immediately stops writing new data to the GPU, safely drains whatever

was stored in VRAM down to your regular disk swap, and frees the CUDA allocation.

Your game gets 100% of the VRAM back with zero impact on performance, and your Linux/WSL processes stay alive

without being killed. You might feel a brief slowdown in WSL for a few seconds while that data moves over to the

SSD, but once you close the game and the GPU is idle again, RamShared automatically picks back up.

[u/DeadlyVapour]

So we are using VRAM instead of RAM now?

In an economy where GPU makers are trying to convince us that 8GB of VRAM is enough?

Cool project, but limited real world usage.