However, there's some interesting things going on in WSL 2 versus a "normal" Hyper-V virtual machine. For example, a Linux distro running on WSL can (and will) use GPU partitioning (aka PCI/GPU passthrough) and a special implementation of DirectX enabling the installed video card to accelerate graphics within X and/or Wayland.
Although this feature can be enabled with a lot of hacking in both the Linux guest and vanilla Hyper-V on the host (the latter through Powershell) it is officially unsupported on Windows 10 and Windows 11, and is only supported on Windows Server.
Imagine licensing and installing Windows Server to run Linux software through WSL
Using GPU passthrough, however, is allowed. WSL2 does this by using the existing Mesa/DRI/DRM open source stack, but instead of a GPU-specific DRM driver, it is one that speaks WDDM (the DRM equivalent in the Windows driver stack), and only requires a GPU-specific ennoblement package (provided by the vendor, and matches the Windows driver it is talking to; AMD, Nvidia, and Intel all ship one inside of WSL2).
If it was enabled on Pro, I would use PCI passthrough. I use hyper-v for a Linux dev environment on a windows workstation. My NIC supports virtual functions, so if I could passthrough one to the dev VM, I wouldn't need software bridging and that might be nice. (OTOH, I don't know if my motherboard has reasonable passthrough groups and all the other stuff that makes passthrough never work for me)
It relies upon SR-IOV and only several server-specific Nvidia GPUs are listed as supported.
Intel's Flex dGPUs and Arc iGPUs have supported SR-IOV for years now, but they aren't listed there. It would be super awesome if Microsoft could add it for Intel Arc iGPUs, desktop versions of Windows, and WSL2! Intel's GPU SR-IOV already works with KVM on Linux!
The keyword to search for: "GPU-P"
https://learn.microsoft.com/en-us/windows-server/virtualizat...
"The Linux Kernel Hidden Inside Windows 10"
https://youtu.be/_p3RtkwstNk?si=V9vhvrdDOLu2Durr
WSL Pico Process Overview
https://learn.microsoft.com/de-de/archive/blogs/wsl/pico-pro...
The same Drawbridge technology is used to run SQL Server on Linux.
https://arstechnica.com/information-technology/2016/12/how-a...
We're using a lot of WSL in CI - we're mostly Linux based, but for some stuff toolchains came up which didn't work nicely with wine (like MSVC). So for us we want a Linux system that seamlessly can execute Windows stuff in a Linux based build process. WSL1 can do that, WSL2 can be kicked into working somewhat, but needs quite a few ugly workaround as they're not sharing a process namespace or file descriptors. While the faster IO would be nice that's pretty much the only thing we'd care about - and wouldn't work here, as we need shared access to the files. And while we could access the WSL2 files from Windows side that's even slower than just using WSL1.
https://clang.llvm.org/docs/MSVCCompatibility.html
https://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf
XWin for the CRT/SDK:
https://github.com/Jake-Shadle/xwin
https://jake-shadle.github.io/xwin/
A while ago I got some Python C extension modules building using this approach, but didn't push it any further.
LOL, this made my day :P
Here is the tracking issue:
https://github.com/microsoft/WSL/issues/12103
And if nothing works you can still manually optimize.
https://superuser.com/questions/1827953/reclaim-wsl2-disk-sp...
WSL2 is a bit like Firecracker for Linux. It's a lightweight VM, with a lot of optimizations here and there. For faster startup, lower memory footprint and so on.
PS: which means you need a lot of memory, if you use WSL2 extensively (multiple Docker containers for example). 8-16 GB on top of your usual workloads is a good starting point. Docker on WSL2 is not a lot of fun with less than 20 GB system memory.
Also the difference to Apple tax in SSDs and RAM remains, or do you think Apple will let go of their beloved margins on top?
Contrary to Apple, we can still add RAM and SSDs in many models, and chose which brands we buy.
Any idea how they do this? My WSL2 starts insanely fast, like about 1-2 seconds. I've never seen a linux distro natively boot that fast. Assuming they suppress any sort of BIOS startup screen for starters, but what else?
And when you run multiple "distributions" or instances, they all share the same running VM and kernel. So after a one-time startup of the VM+kernel, opening more distributions/instances is like starting new system containers (similar to lxc/lxd or systemd-nspawn, which are also very quick to spawn on Linux) rather than new VMs. The architecture is quite similar to Linux-on-ChromeOS (Crostini).
dmesg looks like the kernel is booting up normally, so I guess they don't use some memory snapshots magic.
I guess they just tweaked the kernel and the hypervisor to start up fast. There is also no BIOS/UEFI delay.
\\wsl$
WSL2 is more capable, but it's not Windows anymore. I might as well run a proper Linux VM or dual boot. Better yet, I'd rather run a Windows VM in a bare metal Linux OS. Why even bother with WSL2? What's the value add?
Of course this comes down to whether you care or not about the integrations with Windows.
Is the reverse also true? Does Wine face any similar performance problems?
They made it much better with Dev Drives, that use ReFS instead of NTFS and disables most of the filters in the filesystem stack.
But the filesystem performance really put a huge spoke in this. I thought everything was better with WSL2, but I was surprised to see that MS hasn't engineered some driver or something that would make this much more performant or pass-thru so that you can have a directory on windows but also have it perform really well in the VM.
But also pnpm has quite decent performance on NTFS, it uses symlinks
Listing large directories is slow. But it is what it is.