upvote
I've done a lot of in-depth WSL2 work, so I'm just aware of its particulars, but to cite some documentation-

https://learn.microsoft.com/en-us/windows/wsl/about

"WSL 2 uses virtualization technology to run a Linux kernel inside of a lightweight utility virtual machine (VM). Linux distributions run as isolated containers inside of the WSL 2 managed VM. Linux distributions running via WSL 2 will share the same network namespace, device tree (other than /dev/pts), CPU/Kernel/Memory/Swap, /init binary, but have their own PID namespace, Mount namespace, User namespace, Cgroup namespace, and init process."

(under "What is WSL2"?)

https://www.docker.com/blog/new-docker-desktop-wsl2-backend/

"WSL 2 runs all distros in the same utility VM, sharing the same Kernel."

If you run multiple distros take a look at the process manager and find the single vmmem or vmmemWSL (newer versions have the latter). That single instance is all of the instances, and all of the docker containers you might be running as well, each with namespace isolation (with WSL2 having intentional bridging between them for convenience). Visualise it by doing something intensive in any of them and seeing the single process react, because that's the single utility VM responsible for all of them. Further while starting up the first WSL2 instance or Docker container is expensive, requiring the initialisation of all of the resources for the utility VM and the memory to support it, subsequent iterations are much less expensive.

reply
Thanks, it wasn't out of doubt that I asked, but it seemed having a reference to point at would help resolve the contention. The Docker blog post covered a lot more detail, even about WSL2, which was really informative and I hadn't seen.

I wonder exactly how much work "container" is doing in that Microsoft blog post's description, because it doesn't seem like it's the same kind of environment as a runc or containerd container?

I also wasn't quite sure how much detail to infer from the behavior of vmmemWSL or vmcompute.exe, because my casual understanding is that there's some adaptation layer that handles mapping Linux calls to Windows calls. It seems reasonable to allow for process mapping or accounting shenanigans for any number of good reasons.

reply
>there's some adaptation layer that handles mapping Linux calls to Windows calls

This was how WSL1 functioned. It used a shim layer, and honestly it was pretty neat for a lot of the basic stuff. It fell apart if you were doing more complex/advanced stuff, however, as there were many missing cases and exceptions.

WSL2 instead uses that utility VM, with a couple of special Microsoft kernel drivers to interact with the host system.

reply