Quem roda workloads pesados no Linux ou no WSL2 — compilação de projetos grandes em Rust ou C++, containers Docker, inferência de modelos locais — já passou por aquele travamento completo do sistema quando a RAM física esgota e o kernel cai em swap thrashing no disco.

Ao mesmo tempo, olhando no `nvidia-smi`, você vê uma GPU com 6GB ou 8GB de memória GDDR6 ultrarrápida ficando completamente ociosa durante a compilação.

Para resolver isso sem precisar alterar ou recompilar o kernel do host, escrevi o **RamShared**, um driver userspace em Rust que aloca a VRAM ociosa via CUDA Zero-Copy Direct DMA e a expõe para o Linux como um dispositivo de bloco real (`/dev/ublkb0`) utilizando o subsistema `ublk` (Linux 6.0+) e `io_uring`.

---

Benchmarks Reais Medidos com `fio` (4KB Random Read, QD1 no WSL2):

* **Swap em disco VHDX/SSD padrão:** ~2.114 µs (2.1 ms) de latência | ~336 IOPS * **RamShared NBD (VRAM):** ~326 µs de latência | ~9.6k IOPS * **RamShared ublk (io_uring):** **~8 µs** de latência (264x mais rápido / queda de 99.6%) | **~22k+ IOPS** * **Throughput de Leitura Contínua:** **8.53 GB/s** (saturação do barramento PCIe 3.0/4.0 x16).

---

Por que isso faz diferença na prática:

No WSL2, o swap padrão em disco passa por uma cadeia pesada de virtualização: `ext4 -> VHDX -> Hyper-V -> NTFS -> Host SSD`.

Cada page fault síncrono leva mais de 2ms, o que faz a interface e o terminal congelarem inteiros durante picos de memória. Ao desviar esse tráfego diretamente para a VRAM da GPU via PCIe DMA com `ublk`, a latência cai para microsegundos de um dígito (8 µs), eliminando os travamentos e impedindo o kernel OOM Killer de matar a compilação.

---

Proposta Upstream no WSL2 (Microsoft):

Abrimos uma RFC formal diretamente no repositório oficial da Microsoft pro WSL2 propondo suporte nativo a dispositivos de bloco backed por VRAM em máquinas virtuais Hyper-V: 👉 **RFC Issue:** https://github.com/microsoft/WSL/issues/41054

O projeto é 100% Rust, de código aberto: 👉 **GitHub:** https://github.com/emersonbusson/ramshared

Se alguém tiver dúvidas sobre a implementação com `ublk`, `io_uring` em userspace ou tradeoffs de latência via DMA, fico à disposição nos comentários!

**When your PC runs out of RAM, use idle GPU memory as a safety cushion — and give it back if the GPU gets busy.**

I built **RamShared** (Rust, Linux/WSL2, NVIDIA): a practical way to borrow **idle graphics memory** when system RAM is tight, without pretending GPU memory is as safe/fast as main RAM.

## Problem (human)

You’re compiling / running containers / drowning in tabs. RAM is gone. The machine starts thrashing the **SSD**. Meanwhile the **GPU memory** is often almost empty. You already paid for that silicon.

## Why not “just put all swap on the GPU”?

When Windows reclaims graphics memory under pressure, that memory can get **very slow**. We measured about **1.2 seconds** for a tiny read in the bad case. If that were your *first* emergency store, the whole machine freezes. So GPU memory is only a **second** cushion — and we can **give it back**.

## Design (still short)

```text

Need memory? → 1) compressed RAM (zram) — first, fast

→ 2) idle GPU memory — second, colder

→ 3) disk (SSD / VHDX) — last resort

When your PC runs out of RAM, use idle GPU memory as a safety cushion — and give it back if the GPU gets busy.

I built RamShared (Rust, Linux/WSL2, NVIDIA): a practical way to borrow idle graphics memory when system RAM is tight, without pretending GPU memory is as safe/fast as main RAM.

Problem (human)

You’re compiling / running containers / drowning in tabs. RAM is gone. The machine starts thrashing the SSD. Meanwhile the GPU memory is often almost empty. You already paid for that silicon.

Why not “just put all swap on the GPU”?

When Windows reclaims graphics memory under pressure, that memory can get very slow. We measured about 1.2 seconds for a tiny read in the bad case. If that were your first emergency store, the whole machine freezes. So GPU memory is only a second cushion — and we can give it back.

Design (still short)

Need memory?  →  1) compressed RAM (zram)     — first, fast
              →  2) idle GPU memory           — second, colder
              →  3) disk (SSD / VHDX)         — last resort

If latency spikes / host pressure: stop using the GPU cushion, data slides to disk, apps keep running.

Numbers (measured)

• Bad case under host GPU reclaim: up to ~1.2 s for a small read (why GPU is second, not first).
• Faster path ~241 µs median vs older path ~326 µs (same window, multi-run).
• Stress drill: ~500 MB on GPU tier, ~480 MB moved back, 0 corruption.

Try it

./scripts/quickstart.sh
sudo ./target/release/ramshared check
sudo ./target/release/ramshared up --vram 1024 --zram 1024
swapon --show   # success ≈ three lines: zram + GPU + disk

Honest limits

• Day-1 path is Linux/WSL2 + NVIDIA, not “every GPU / every OS.”
• Not free RAM for maxed-out games.
• We don’t thrash live WSL2 on purpose; heavy tests use isolated VMs.
• Not bare-metal CXL magic — practical workstation tool.

Looking for feedback

Especially from people who’ve fought swap, block devices, CUDA, or WSL2:

1. Second-cushion + give-back vs other APIs under Windows GPU reclaim.
2. What you’d want in a “it just works” install.
3. Where the safety story still feels thin.

Repo + plain FAQ: https://github.com/emersonbusson/ramshared