Working sets & trimming

Paging & page faults described how pages become resident. This chapter is about the other direction: how Windows decides which resident pages to keep, and which to take back, when physical memory is under pressure from everything else running on the machine.

The working set: what's actually resident, right now

A process's working set is the set of its virtual pages that are currently backed by physical RAM. This is a genuinely different quantity from commit (the total virtual memory the process has reserved and is entitled to use) — a process can have a large commit size and a comparatively small working set, if much of what it committed isn't being actively touched right now. This is exactly why Task Manager shows multiple, meaningfully different memory columns for the same process: "Commit size" and "Working set" answer different questions, and conflating them is a common source of confused memory-usage conversations.

Trimming: reclaiming pages under pressure

When system-wide memory is under pressure — many processes competing for a limited pool of physical pages — the Memory Manager can trim working sets: removing pages from a process's resident set to free physical frames for something else that needs them more urgently right now. Trimmed pages aren't necessarily discarded outright; if they're unmodified (a file's original content, or a DLL's code section) they can simply be dropped, since the same content is still available from its original backing file. Modified private data has to be written out (to the page file, typically) before the frame can be reused, which is more expensive — one reason heavy trimming under sustained pressure tends to correlate with rising disk activity even before the system is visibly thrashing.

Why this makes things feel slow before it looks catastrophic

The user-visible consequence of aggressive trimming is subtle at first: a process whose working set just got trimmed doesn't crash or error out — its next access to a trimmed page simply becomes a fault (a soft fault, if the page is still findable in memory somewhere; a hard fault, if it genuinely has to come back from disk, per Paging & page faults). Under real pressure, a process can end up repeatedly having pages trimmed and then re-faulted back in as it keeps touching the same working set of data other processes keep forcing back out — a pattern that shows up as sluggishness and rising fault counts well before the more dramatic, obviously-named "thrashing" state.

The cache manager complicates the picture, usefully

File data cached in memory (covered in The Cache Manager) competes for the same physical page pool as ordinary process working sets — and Windows deliberately lets that cache grow to use otherwise-idle RAM, on the reasoning that unused RAM caching recently-read file data is more useful than unused RAM sitting empty. This is exactly why "available memory" numbers on a healthy Windows machine often look lower than a naive read of installed RAM minus running processes would suggest — a large chunk of "used" memory can genuinely be reclaimable file cache, not memory something would actually miss if reclaimed.

A worked example: a game stuttering when many other apps are open

A foreground game whose working set keeps getting trimmed because several other applications (and the file cache serving them) are also competing for physical memory will show exactly the symptom described above: intermittent stutters correlating with re-fault activity, even if the game's own total committed memory comfortably fits within installed RAM in isolation. The problem isn't the game's memory footprint alone — it's the combined pressure from everything running simultaneously, forcing repeated trim-and-refault cycles on data the foreground app needs constantly.

A common mistake

Reading Task Manager's single "Memory" percentage as the complete story badly oversimplifies what's actually happening. Commit, working set, private bytes, and shared/cached memory are genuinely different quantities that can move independently of each other, and a full diagnosis of a memory-pressure problem usually needs at least the distinction between committed and resident, plus an eye on hard-fault rate, rather than one aggregate number.

Where this connects

• Pool & heap covers the allocators that actually hand out the memory whose residency this chapter describes.
• The Cache Manager is the other major, competing consumer of the same physical page pool.