r/bashonubuntuonwindows

Fiz um driver de bloco em Rust que usa VRAM ociosa da GPU como storage de 8.53 GB/s no Linux (ublk + io_uring)
▲ 33 r/bashonubuntuonwindows+3 crossposts

Fiz um driver de bloco em Rust que usa VRAM ociosa da GPU como storage de 8.53 GB/s no Linux (ublk + io_uring)

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!

u/bussondev — 9 hours ago
▲ 27 r/bashonubuntuonwindows+1 crossposts

What's the best way to SSH directly into WSL2 from another Linux machine?

Hi everyone,

I'm a bit confused about what the "right" way to do this is.

I have a Windows PC running Debian in WSL2, and I have another Debian laptop.

My goal is to make WSL my main development environment and SSH into it from the laptop.

I first tried using the Windows OpenSSH server with ForceCommand to launch WSL. That actually lets me log in directly into WSL, which looked perfect at first. The problem is that normal SSH commands don't seem to work.

For example:

ssh my-pc

works fine, but

ssh my-pc "pwd"

just hangs. rsync also hangs because it uses remote commands over SSH.

So I started wondering if this is just the wrong approach.

I already have sshd running inside WSL, but since WSL is using NAT, it gets a 172.x.x.x IP that changes, so I don't know if that's supposed to be the way either.

I've been reading about mirrored networking, port forwarding, Windows OpenSSH, etc., and now I'm more confused than when I started.

For those of you who use WSL as your main Linux machine, what's the recommended setup nowadays?

Ideally I'd like:

  1. ssh my-pc

  2. ssh my-pc "command"

  3. rsync

  4. scp

  5. VS Code Remote SSH

to all work without weird workarounds.

Am I overcomplicating this? How are you guys doing it?

Thanks!

reddit.com
u/logikwright — 7 days ago

WSL2 Ubuntu and cron jobs

Hi. I was working through a bash tutorial and a portion talked about cron jobs. I edited the crontab for both regular user and root to run a test script. In both instances, the script never ran. /var/log/syslog shows when the crontabs were edited, etc. Also there are these entries:

2026-08-13T13:36:02.393235-07:00 t1nk3rm0b1l3 wsl-pro-service[1730]: #033[33mWARNING#033[0m Daemon: could not connect to Windows Agent: could not get address: could not read agent port file "/mnt/c/Users/computertinkerer/.ubuntupro/.address": open /mnt/c/Users/computertinkerer/.ubuntupro/.address: no such file or directory

These entries are there whether the cron job was set for the regular user or root. Any insights or tips highly appreciated. This is my first time ever dealing with cron jobs. Thanks.

reddit.com
u/ComputerTinkerer71 — 7 days ago

Experimenting with WSL Containers: I built a CLI for Compose-like development workflows

I built a small CLI to make WSL Containers feel more like Docker Compose / dip.
I mainly built it because I wanted to use WSLC for my own development workflow, but ran into gaps around bind mounts, build contexts, compose-like workflows, and run.

I’m curious whether anyone else experimenting with WSLC has run into the same problems, or whether I’m solving these in the wrong layer.

https://github.com/slidict/wip

u/Expert-Ad4676 — 10 days ago

I built a venv-style environment manager for WSL2 — and benchmarked it honestly against Docker Desktop

I kept spinning up throwaway WSL distros by hand — `wsl --export`, `--import`, remember

which one belonged to which project, forget to clean up. So I wrote a CLI that treats a

WSL2 instance the way venv treats a Python environment: it belongs to the project

directory, one command creates it, one command destroys it.

cd my-project

lenv init

lenv run "ls -a"

lenv destroy

Config lives in .lenv/ next to your code. No daemon, no Dockerfile, no registry.

Because the obvious question is "why not Docker Desktop," I benchmarked it properly and

published the results including the parts where I lose:

- Warm command execution: `docker exec` beats `lenv run` by ~46ms. Docker's CLI is compiled

Go, mine is Python. That gap is structural.

- True throwaway (create → run → destroy): Docker wins by ~8x. `lenv init` costs ~2.8s.

- Cold restart of a stopped environment: tie.

- Idle RAM: Docker Desktop ~2.4GB working set. lenv's marginal cost over a machine that

already runs WSL2 is ~0.1GB.

- Disk: Docker Desktop install+data ~5.4GB. A lenv environment is ~100MB.

So it's not faster. It's lighter, and it doesn't leave anything running. If you're on a

16GB laptop and Docker Desktop's idle footprint annoys you, that's the pitch.

Benchmark with method and raw numbers: https://github.com/pranavpd24/lenv/blob/main/BENCHMARK.md

Repo: https://github.com/pranavpd24/lenv

pip install lenv-manager

Not a container engine — no image layers, no registry, no build. And not a security

sandbox: WSL2 distros share the host VM kernel.

https://i.redd.it/jys3m8m6p4ih1.gif

Happy to take criticism on the methodology, it's a single-machine benchmark.

reddit.com
u/dpranav24 — 12 days ago

Virtual or Pass-thru hardware resources?

I can probably ask any AI this question, but I want to be part of, and contribute to this community.

.

My Specs:

I'm running the latest version of Windows 11 Pro and fully up to date on an Samsung M.2 1TB drive. My system specs are AMD Ryzen 9 3900x, 32GB DDR4 RAM, and MSI Ventus 3 Geforce RTX 4070 OC edition (12GB). All other drives are a mix of SSDs all 500GB (Samsung, Crucial, and Western Digital).

.

My question:

I've been testing local AI in a Virtualbox guest session running Linux Mint 22.3 (up to date). I provide my specs because the one thing I know about Virtualbox is it using virtual hardware. I also run a Proxmox node and know I can pass the GPU through to the VMs and Containers if needed. So my question is, do WSL1 or 2 use my physical hardware (i.e. the AI will have use of the Nvidia GPU or other physical hardware) or is WSL like Virtualbox and just emulates hardware?

reddit.com
u/zentsang — 12 days ago