With the release of the WSL 3.x stack, Microsoft bumped the default virtualization runtime and advanced the shipped guest kernel from the 6.6 LTS branch up to 6.18.

WSL upgrades often claim generalized performance gains, but marketing bullet points rarely translate directly to developer workloads. To see what actually changed under the hood, I ran side-by-side benchmark suites comparing WSL 2.6.3.0 (Linux kernel 6.6.87.2) against WSL 3.0.2.0 (Linux kernel 6.18.40.1).

In our earlier look at The Security Tax in WSL 2, we showed how kernel-level mitigations for CPU speculative execution vulnerabilities (Spectre, Meltdown, Retbleed) imposed a steep penalty on developer tasks. On a real-world Go backend compilation workload, turning off mitigations slashed kernel system time by 45.7% and delivered a 31.7% drop in wall-clock compile time.

With the rollout of WSL v3.0.2 (running Linux kernel 6.18.40.1-microsoft-standard-WSL2), how does the security tax hold up today? Does modern hypervisor paravirtualization eliminate the overhead, or are developers still paying an invisible performance toll on syscall-heavy workloads?

In my previous post, we looked at how default Google guest daemons consume over 15% of available memory on a 1 GB Google Compute Engine (e2-micro) instance, pushing standard Debian images into SSH lockout during moderate memory pressure.

To see how far we could push the lower boundary of GCE instances without sacrificing reliability, I built a custom minimal Alpine Linux image (alpine-3-24-1-uefi-lite-v5).

We subjected this image to a punishing synthetic stress harness: pinning 900 MB to 1,250 MB of memory, driving 16 concurrent worker threads, and executing over 167,000 sub-processes in five minutes. While standard Debian froze solid, the Alpine instance maintained sub-second SSH logins and responsive interactive keystrokes.