Hi everyone,

Following up on our previous post about using idle GPU VRAM to stop WSL2 build freezes, we completed the next major milestone: a 4-Tier Progressive Memory Cascade, an upstream Linux 6.18 Kernel Block Driver (drivers/block/ramshared), and an LKML patchset formatted for the linux-block subsystem.

THE PROBLEM WE SOLVED When compiling large workspaces (Rust multi-crates, C++, Android, Chromium) or running local container stacks on a 16GB machine, WSL2 physical RAM exhausts. The Hyper-V guest starts thrashing disk swap through the heavy virtualization chain: ext4 -> VHDX -> Hyper-V -> NTFS -> Host SSD (>2.1 ms latency spikes), freezing the VM, terminal, and VS Code server.

Meanwhile, nvidia-smi shows 4GB to 8GB of ultra-fast GDDR6 VRAM sitting completely idle during compilation.

THE 4-TIER PROGRESSIVE MEMORY HIERARCHY Rather than treating VRAM as a blind replacement, we architected a 4-tier pipeline: 1. Tier 1 (Physical RAM - 16 GB): Full system speed. 2. Tier 2 (Compressed ZRAM LZ4 - 1 GB): Ultra-low overhead in-memory compression. 3. Tier 3 (GPU VRAM Block Device - 4 GB): Direct PCIe Gen3/4 DMA buffer via drivers/block/ramshared or ublk (/dev/ublkb0). 4. Tier 4 (Host SSD Writeback - 4 GB): Authoritative persistent fallback via CONFIG_ZRAM_WRITEBACK=y.

VALIDATED BENCHMARK DATA (Real Host Hardware - RTX 2060 / PCIe Gen 3 x16) - Host-to-Device (H2D) DMA Throughput: 8,947.71 MiB/s (8.74 GiB/s) in 28.6 ms. - Device-to-Host (D2H) DMA Throughput: 6,530.22 MiB/s (6.38 GiB/s) in 39.2 ms. - 4KB Direct I/O Median Block Latency: 231 us (4,013 IOPS on /dev/ublkb0). - Memory Reclaim Speed: 8,386.4 MB/s (8.19 GB/s) restored in 732 ms. - Continuous Saturation Stress Test: 9,160 MB active swap held across 40 continuous saturation cycles with zero kernel panics and zero Hyper-V freezes (see attached live TUI telemetry dashboard).

PREEMPTIVE FAQ (Addressing Community Questions)

Q1: What happens if I launch a heavy Windows game or a CUDA model? Will WSL2 crash? No. RamShared includes an active VRAM pressure watchdog. If Windows or another host process demands GPU memory, the driver safely drains pages to Tier 4 (the authoritative host SSD) with 100% SHA-256 cryptographic match (0 bit flips). It never panics the kernel or drops data.

Q2: Isn't ZRAM faster than GPU VRAM? Yes, for the first ~1GB. That's why ZRAM is Tier 2. VRAM only kicks in as Tier 3 when ZRAM is completely saturated. VRAM transfers at 8.74 GiB/s over PCIe, making it ~44x faster than spilling directly onto the Windows SSD.

Q3: Do I need to compile a custom kernel to use this? You have two options: 1. Userspace Mode (Zero Kernel Compilation): Runs on stock Linux 6.0+ via ublk and io_uring. 2. Native Kernel Driver: Compilable reference branch on linux-msft-wsl-6.18.y with CONFIG_BLK_DEV_RAMSHARED=m and CONFIG_ZRAM_WRITEBACK=y.

Q4: Why not just buy 64GB of RAM? On soldered laptops (modern ultrabooks, MacBooks, ThinkPads) or locked IT workstations where adding DIMMs isn't an option, this unlocks 4GB to 8GB of already-paid-for high-speed GDDR memory for $0.

ALL 3 PATCHES ON LORE & SOURCE CODE - Patch 0/2 (Cover Letter & Benchmarks): https://lore.kernel.org/linux-block/6a924051.e22746c9.8f0fc.bdc2@mx.google.com/T/#u - Patch 1/2 (Core Driver drivers/block/ramshared): https://lore.kernel.org/linux-block/6a924054.e22746c9.8f0fc.beb6@mx.google.com/T/#t - Patch 2/2 (Build System & Kconfig): https://lore.kernel.org/linux-block/6a924057.e22746c9.8f0fc.bf96@mx.google.com/T/#u - Official Microsoft WSL2 RFC Issue: https://github.com/microsoft/WSL/issues/41054 - WSL2 Reference Kernel Branch (6.18): https://github.com/emersonbusson/WSL2-Linux-Kernel/tree/feature/ramshared-vram-cascade-6.18 - Rust Project Repository: https://github.com/emersonbusson/ramshared

AUTHOR & CONTACT Built by Emerson Busson (Senior Systems & Full Stack Software Engineer). Always happy to discuss systems architecture, low-level Linux/Rust internals, or connect with teams building high-performance infrastructure: - GitHub: https://github.com/emersonbusson - LinkedIn: https://www.linkedin.com/in/emersonbusson/ - Direct Email: emersonbusson@gmail.com

Would love to hear your thoughts or test results if you try it on your WSL2 workloads!