WSL 2 Speeds Up Windows File Access with Per-Device DMA Pools for Virtiofs

A May 2026 change to WSL 2 gives each virtio device its own dedicated SWIOTLB bounce-buffer pool, eliminating contention that previously forced all virtiofs mounts and the virtio network adapter to queue through a single shared DMA region below the 4 GB boundary. The kernel now reserves a contiguous physical range per device at boot and exposes it via sysfs, and the WSL service injects a per-device swiotlb= option at device creation. The fix requires Microsoft.WSL.Kernel 6.18.26.3-1 with DeviceHost 1.2.29-0; older kernels print a notice prompting an update.

The change matters most for workflows that straddle the Windows/Linux boundary — building a project stored on a Windows drive from inside a Linux distro, where every file read crosses the VM boundary. Virtiofs, opt-in since around 2021 via virtiofs=true in .wslconfig, already cut serialization overhead compared to the default Plan 9 transport, and recent PRs added device reuse and shared mmap without DAX. Per-device DMA pools close one of the last remaining bottlenecks on that path, and VirtioProxy networking benefits from the same infrastructure.

Plan 9 over a Hyper-V socket, capped at a 64 KB message size, remains the default — virtiofs is still opt-in. Users wanting the speedup need virtiofs enabled, a current pre-release kernel, and at least ~1 GB of VM RAM to leave 64 MB of headroom for the SWIOTLB pool. The broader arc: each WSL generation has narrowed the cross-OS file I/O gap that opened when WSL 2 traded WSL 1’s in-kernel DrvFs for a real Linux VM.