How WSL2 Actually Manages Memory (and Why vmmem Grows)

The vmmem (or Vmmemwsl) process visible in Windows Task Manager, sometimes consuming what looks like an alarming amount of RAM, represents WSL2’s entire lightweight virtual machine — understanding how its memory allocation actually works clarifies whether that number is a problem or expected behavior.

Why WSL2 needs a dedicated memory allocation at all

Because WSL2 runs a genuine Linux kernel inside an actual lightweight VM (unlike WSL1’s syscall-translation approach, which needed no separate memory pool at all), that VM needs its own allocated memory, separate from what any individual Linux process inside it uses directly — vmmem represents this VM-level allocation as a whole, not any single process running inside it.

How dynamic memory allocation is supposed to work

WSL2 is designed to allocate memory from Windows dynamically, growing as Linux-side processes need more, rather than reserving a large fixed amount upfront — in principle, this should mean vmmem shrinks back down once Linux-side memory pressure eases, similar to how memory ballooning works in other virtualization contexts.

Why memory reclaim historically lagged behind expectations

In practice, particularly on earlier WSL2 versions, the VM was often slow to actually release memory back to Windows even after the Linux-side workload that consumed it had finished — Linux’s own page cache behavior (keeping recently-used file data cached in memory speculatively) compounds this, since cached-but-technically-reclaimable memory still shows up as VM memory usage from the Windows side.

What you can directly control via .wslconfig

%UserProfile%\.wslconfig

[wsl2]
memory=4GB

Setting an explicit memory ceiling caps how much RAM the WSL2 VM can ever claim, regardless of Linux-side demand — a hard limit rather than the dynamic, demand-driven allocation than can otherwise grow uncomfortably large under sustained heavy use.

The manual reclaim option

# from within the WSL distro:
echo 1 > /proc/sys/vm/drop_caches

# from Windows, restarting the whole WSL2 VM:
wsl --shutdown

Dropping the Linux-side page cache manually can reclaim some memory without a full restart; a full wsl --shutdown fully tears down and releases the VM’s entire memory allocation, at the cost of ending every running WSL session and process.

Why a memory ceiling is a real tradeoff, not a free improvement

Capping memory via .wslconfig prevents vmmem from growing unboundedly, but a ceiling set too low can cause genuine out-of-memory pressure inside Linux-side workloads that legitimately need more — the right number depends on both your physical RAM and what you’re actually running inside WSL, not a single value that’s correct for everyone.

Why this behavior surprises people coming from WSL1

WSL1 users never encountered this specific concern at all, since WSL1’s syscall-translation architecture had no separate VM memory pool to manage — this is a genuinely new category of resource-management consideration that comes specifically with WSL2’s real-kernel-in-a-VM architecture, not a regression from WSL1, but a different tradeoff traded for WSL2’s much better kernel compatibility.

Distinguishing genuine memory pressure from Linux’s own caching behavior

Before assuming a large vmmem figure indicates a problem, check what’s actually driving it from inside the distribution:

free -h

Linux’s free output distinguishes memory genuinely in active use by running processes from memory held as page cache — data cached speculatively because it was recently read or written, reclaimable on demand if a process actually needs that memory back. A large cache figure with comfortable “available” memory reported is expected, healthy behavior, not evidence of a leak or misconfiguration, even though the same memory shows up as consumed when viewed from the Windows side via vmmem.

Setting a ceiling deliberately, based on actual physical RAM

A .wslconfig memory ceiling is most useful set as a deliberate fraction of total physical RAM, leaving enough headroom for Windows itself and other running applications rather than picking an arbitrary round number. On a 32GB machine primarily used for WSL-based development, capping WSL2 at 16–20GB might be entirely reasonable; the same absolute number on an 8GB machine would starve Windows itself. There’s no single correct value — the right ceiling depends on your specific hardware and how much of it Windows and other applications genuinely need to keep functioning comfortably alongside WSL.

The relationship between memory ceiling and swap

[wsl2]
memory=8GB
swap=2GB

WSL2’s own swap setting controls how much disk-backed swap space the Linux environment has available once its memory ceiling is reached, functioning similarly to swap on a bare-metal Linux install — a workload that occasionally exceeds the memory ceiling can page out to swap rather than immediately hitting an out-of-memory condition, at the cost of the performance penalty swap always carries compared to genuine RAM.

Confirming a ceiling change actually took effect

wsl --shutdown

then restarting and checking Task Manager’s vmmem entry, or, from inside the distribution, free -h’s total memory figure, confirms a .wslconfig memory change actually applied — since, like most .wslconfig settings, it requires this full restart rather than taking effect on an already-running instance.

Newer automatic memory reclaim improvements

Later WSL2 releases improved on the original reluctant-reclaim behavior with more proactive memory reclaim logic, narrowing the gap between “Linux no longer needs this memory” and “Windows actually gets it back” compared to earlier WSL2 versions. If a long-standing vmmem growth complaint you remember from an older WSL version seems to have quietly improved, that’s a genuine, documented area of ongoing engineering work rather than something you’re imagining — worth re-testing actual behavior on a current WSL version before assuming old advice about aggressive manual cache-dropping still applies as strongly as it once did.

Why an unbounded ceiling isn’t automatically the wrong choice either

Leaving .wslconfig without an explicit memory setting isn’t a mistake by default — WSL2’s built-in default ceiling (historically around 50% of total physical RAM, or 8GB, whichever is larger, though this default has been refined over time) is a reasonable starting point for many single-purpose development machines. An explicit, lower ceiling becomes worth setting specifically once you’ve observed real contention between WSL2 and other applications for memory on your particular machine, rather than as a precautionary default applied before any actual problem has been observed.

Related:

Sources: