Add kunal-chowdhury.com on Google to see more of our coverages in your search results.
If you have ever compiled a local large language model runtime like llama.cpp, vLLM, or custom CUDA kernels inside Windows Subsystem for Linux (WSL 2), you have probably noticed something frustrating. Even on a multi-core processor paired with a fast NVMe SSD and an NVIDIA RTX graphics card, parallel CMake and Ninja builds inside WSL often take twice as long as they do on a native Ubuntu installation.
The culprit is not virtualization overhead from Hyper-V, but two conservative default settings buried inside WSL's per-distribution /etc/wsl.conf and global %USERPROFILE%\.wslconfig files. Here is how disabling automatic Windows path injection and switching WSL's memory reclamation mode from aggressive cache dropping to gradual reclaim cuts parallel C++ and CUDA compile times in half.
appendWindowsPath=false inside /etc/wsl.conf stops CMake, Ninja, and nvcc from scanning dozens of slow /mnt/c/ Windows directories on every compiler fork.autoMemoryReclaim from its aggressive dropCache default to gradual in %USERPROFILE%\.wslconfig prevents WSL from wiping cached C++ headers and ccache objects between builds..wslconfig stops parallel CUDA cicc and ptxas threads from hitting swap.vhdx disk thrashing or OOM crashes.~/projects on the Linux virtual disk instead of /mnt/c/ avoids Plan 9 over Hyper-V socket penalties while keeping full CUDA GPU passthrough.wsl --shutdown and wait 8 seconds so the Hyper-V utility VM reloads both configuration files cleanly.
When you compile custom inference engines like llama.cpp (with GGML_CUDA=ON), vLLM, or FlashAttention to power local Retrieval-Augmented Generation (RAG) pipelines or local Model Context Protocol (MCP) servers, the build system spawns thousands of short-lived compiler, assembler, and linker processes. Even on a high-end PC configured with our modern Windows 11 developer workstation guide, default WSL 2 settings sabotage that workload in two invisible ways.
First, WSL automatically injects your entire Windows host PATH into the Linux environment, forcing every subprocess lookup to cross the virtual machine boundary over a slow Plan 9 (9P) file server. Second, WSL caps your Linux virtual machine at just 50% of your physical RAM while defaulting its memory reclamation engine to dropCache, which ruthlessly purges cached header files the moment a compilation step pauses.
Run echo $PATH inside a stock Ubuntu WSL terminal and you will see dozens of /mnt/c/Program Files/... entries appended at the tail end. Whenever CMake, Ninja, pkg-config, or nvcc checks for helper binaries or compiler wrappers during a multi-threaded build, Linux stats each directory in $PATH—crossing the Hyper-V socket into Windows NTFS via DrvFs (Plan 9 protocol) thousands of times per minute.
As documented in the official Microsoft Learn WSL configuration guide, you can eliminate this bottleneck per distribution by editing /etc/wsl.conf inside your Linux shell (`sudo nano /etc/wsl.conf`) and adding these exact sections:
[boot] with systemd=true to keep background services like Ollama managed cleanly.[interop] with enabled=true and appendWindowsPath=false to strip slow /mnt/c/ folders from $PATH while still allowing you to invoke explicit Windows binaries by full path when needed.[automount] with enabled=true, options="metadata,umask=22,fmask=11", and ldconfig=true so Windows-supplied NVIDIA CUDA libraries remain linked.[gpu] with enabled=true and appendLibPath=true to preserve /usr/lib/wsl/lib/libcuda.so.1 GPU acceleration, as verified in the WSL-UI technical troubleshooting reference.
If you still want to launch Visual Studio Code or Windows Explorer directly from your Ubuntu prompt after disabling automatic Windows path injection, simply create a targeted symbolic link inside /usr/local/bin for those two binaries alone. That way, you keep instant desktop integration without polluting compiler lookup tables with thirty slow Windows system directories.
Next, fix the virtual machine hardware ceiling by creating or editing %USERPROFILE%\.wslconfig on your Windows host (`notepad $env:USERPROFILE\.wslconfig` in PowerShell). When you compile CUDA device code for multiple NVIDIA Compute Capability architectures, each parallel cicc and ptxas compiler thread consumes 1.5 GB to 3 GB of RAM; hitting the default 50% RAM cap on a 32 GB PC forces Linux to thrash against `%Temp%\swap.vhdx` on disk.
Even worse, Microsoft's current default for [experimental] autoMemoryReclaim is dropCache, which immediately dumps the Linux Virtual File System (VFS) page cache whenever CPU activity dips—destroying incremental build speeds when switching between your terminal and Visual Studio 2026 v18.11. Add these parameters to %USERPROFILE%\.wslconfig (adjusting memory=24GB on a 32 GB PC or 48GB on a 64 GB PC):
[wsl2]: set memory=24GB, processors=16 (matching your logical cores), swap=8GB, networkingMode=mirrored, and dnsTunneling=true.[experimental]: set autoMemoryReclaim=gradual and sparseVhd=true so WSL reclaims idle memory slowly in the background without flushing hot C++ header and ccache pages from RAM.
Configuration files alone cannot save a build if your source code sits inside /mnt/c/Users/.... On systems running the latest Windows 11 26H2 update, WSL 2 runs a real Linux 6.18 LTS kernel backed by an ext4.vhdx virtual disk, which delivers near-native NVMe throughput only when files reside inside the Linux root filesystem.
Always clone your repositories (`git clone https://github.com/ggerganov/llama.cpp`) and store your GGUF weights inside ~/projects or ~/models rather than `/mnt/c/`. Also remember the golden CUDA rule for WSL 2: never install the Linux NVIDIA display driver inside Ubuntu, or you will overwrite the para-virtualized Windows stub at `/usr/lib/wsl/lib/libcuda.so.1`—install only the cuda-toolkit package inside Linux.
appendWindowsPath=true forces CMake and Ninja to scan dozens of slow 9P /mnt/c/ paths.nvcc swap thrashing on -j 16 builds.autoMemoryReclaim=dropCache flushes cached C++ headers and object files whenever the VM idles.appendWindowsPath=false in /etc/wsl.conf keeps all compiler lookups on native ext4.memory=24GB (on 32 GB host) allows 12 to 16 parallel nvcc threads with zero swap I/O.autoMemoryReclaim=gradual retains header trees and ccache objects in RAM across builds.
After saving both `/etc/wsl.conf` and `%USERPROFILE%\.wslconfig`, simply closing your Ubuntu tab will not apply the changes—Microsoft enforces an 8-second rule before a background WSL utility VM terminates. Open Windows PowerShell, run wsl --shutdown, wait a full eight seconds, and verify that wsl --list --running reports no active distributions before relaunching your terminal.
Once back inside Ubuntu, run free -h to confirm your new 24 GB RAM ceiling and echo $PATH to verify that `/mnt/c/` paths are gone while `/usr/lib/wsl/lib` remains active. Then compile llama.cpp on your native ext4 drive using cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j 12 to experience the full two-fold speed jump firsthand.
You do not need to dual-boot Ubuntu on a separate NVMe partition just to compile local LLMs and custom CUDA kernels at full hardware speed. By stripping Windows 9P directories out of your Linux $PATH in /etc/wsl.conf, switching .wslconfig from dropCache to gradual memory reclamation, and giving your WSL 2 VM enough RAM headroom to link in parallel without swapping, your Windows 11 workstation matches bare-metal Linux build times. Have you tuned your .wslconfig for local AI development yet? Share your compile times and hardware specs in the comments below!
