The article argues that the single global swiotlb was the root cause of virtiofs throughput collapsing under concurrent load. By giving each virtio device its own pool with independent locking, contention on the global spinlock disappears and concurrent workloads like npm install and Docker Desktop stop serializing on the same allocator.
By submitting the piece with the framing 'WSL 2 is getting faster Windows file system access,' haydenbarnes endorses the view that this kernel change directly addresses the long-standing /mnt/c performance complaint. The 95-point score signals broad agreement that this is a meaningful fix to a real pain point.
The editorial frames the swiotlb change as one fix in a multi-year saga, noting that WSL 2 inverted WSL 1's tradeoff — fast Linux syscalls but slow Windows file access through 9P/virtiofs. While the per-device pools help, the broader virtiofs bridge design remains the real architectural constraint that has 'not been winning benchmarks' since the transition.
A recent patch series landed in the WSL 2 kernel tree introducing per-device swiotlb pools for virtiofs and the virtio-proxy transport. The change, documented in detail by boxofcables.dev, replaces the single global software I/O TLB — a bounce buffer that virtio devices use to shuttle data between the guest and the host — with a pool dedicated to each device instance. The headline result: contention on the global swiotlb spinlock disappears, and per-device throughput stops collapsing under concurrent load.
For context: swiotlb (software I/O translation lookaside buffer) is the Linux kernel's fallback when a device can't DMA directly to guest memory — common in virtualized setups where the IOMMU isn't passing through, or where memory above a device's addressable range needs to be copied into a reserved low-memory window. WSL 2 leans on this heavily because virtiofs (the file-system passthrough that backs `/mnt/c`, `/mnt/d`, and friends) routes Windows-host file I/O through virtio rings that bounce-buffer their payloads.
Under the old single-pool design, every virtiofs read, every virtio-proxy syscall, and every other virtio device on the box fought for the same allocator. Run `npm install` on a Windows-mounted project while Docker Desktop is also chewing on virtiofs, and you'd watch both grind because they were serializing on the same in-kernel spinlock. The new per-device pools give each virtio device its own slab, with independent locking. Concurrent workloads stop stepping on each other.
The Windows-side file system has been WSL 2's most-complained-about bottleneck since the WSL 1 → WSL 2 transition in 2019. The original WSL used a Windows-native VFS shim that made `/mnt/c` access fast but Linux syscalls slow. WSL 2 inverted that: native Linux filesystem performance inside the VM, but Windows file access through a 9P (later virtiofs) bridge that was — to put it diplomatically — not winning benchmarks. Microsoft's standing advice has been "keep your project files in the Linux filesystem," which works until you need to share with a Windows IDE, an antivirus, or your team's existing tooling.
This patch doesn't change the architecture. It fixes a specific scaling pathology inside it. The interesting part isn't that it makes one virtiofs operation faster — it's that it makes N concurrent operations no longer N× slower than they should be. That's a different class of fix. Single-threaded virtiofs latency was already tolerable for casual file reads; what killed people was running a build, a watcher, and a container at the same time and watching wall-clock time balloon.
The community discussion on Hacker News (95 points and climbing) zeroed in on the same thing: this is the kind of patch you only notice if you understood why your workload was slow in the first place. Most WSL users will see throughput improvements they can't attribute to anything specific — their `npm ci` just stops feeling broken. Power users running multi-container dev environments, where each container mounts a slice of the Windows filesystem, will see the biggest deltas because they were the ones most punished by global-lock contention.
There's also a subtler point about how Microsoft has been engineering WSL: not as a hermetic abstraction but as a stack where the seams between Windows and Linux get optimized one at a time, in public, in the open-source kernel fork. The same week this landed, the WSL kernel repo also took patches for memory ballooning improvements and a virtio-proxy refactor. Microsoft is shipping kernel-level VM optimizations directly into the WSL fork at a cadence that most managed VM platforms don't match.
If your dev loop touches `/mnt/c` — and a lot of Windows-based developers' loops do, whether they admit it or not — you should see meaningfully faster turnaround once this lands in a public WSL build. Concretely: Node and Python projects checked out on the Windows side, Docker bind-mounts pointing at `C:\`, VS Code remote-WSL sessions editing files that live in Windows, and any CI-like workflow that reads or writes through the virtiofs bridge.
The practical guidance hasn't changed: native Linux filesystem is still faster than virtiofs, and you should still keep hot-path source trees in `~/` if you can. But the cost of crossing the boundary is dropping, which matters for the workflows where you can't avoid it — most notably team environments where the canonical checkout lives on the Windows side and only some teammates use WSL.
For anyone running container-heavy WSL setups (Docker Desktop, Podman, Rancher Desktop), this should also reduce the "my container got slow when I started a build" tax. The per-device pools mean each container's virtiofs mount doesn't compete with the others for the same allocator. If you've been carrying tribal knowledge like "only run one watch process at a time on WSL," you can probably retire it.
The pattern here — fix one global lock at a time, profile the next bottleneck, ship — is what mature kernel performance work looks like. WSL 2 went from "the new thing with a slow filesystem bridge" to "a virtualization stack quietly accumulating real kernel-grade optimizations," and the gap between WSL and a hand-tuned KVM dev box keeps narrowing. The next interesting question is whether Microsoft pushes any of these per-device pool patches upstream into mainline Linux, where any virtio-heavy workload — not just WSL — would benefit. Given recent history with WSL kernel patches making it into mainline, the answer is probably yes, eventually.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.