Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have seen this question and it is not a duplicate, title notwithstanding, since the given answer does not answer my question.

I currently have a Windows XP system that reports system Commit usage as less than the Physical Memory usage. My understanding was that System Commit was the total amount of pagefile plus RAM usage. As phrased by Wikipedia:

The amount of pagefile that would be used if all current contents of RAM had to be removed.

So how is it possible to have RAM usage higher than the sum of RAM and pagefile usage?

Process Explorer screenshot

share|improve this question
up vote 7 down vote accepted

The commit charge amount doesn't include all physical memory; it only counts all physical memory that could be paged to disk.

From Pushing the Limits of Windows -- Virtual Memory (I'd recommend reading the entire article)

As you’d expect from the description of the commit guarantee, the commit limit is the sum of physical memory and the sizes of the paging files. In reality, not quite all of physical memory counts toward the commit limit since the operating system reserves part of physical memory for its own use.


Not all the virtual memory that a process allocates counts toward the commit limit. As you've seen, reserved virtual memory doesn't. Virtual memory that represents a file on disk, called a file mapping view, also doesn't count toward the limit unless the application asks for copy-on-write semantics, because Windows can discard any data associated with the view from physical memory and then retrieve it from the file. The virtual memory in Testlimit's address space where its executable and system DLL images are mapped therefore don't count toward the commit limit. There are two types of process virtual memory that do count toward the commit limit: private and pagefile-backed.

So some OS memory usage doens't count to that limit as well as memory mapped files. In Windows all EXE and DLL files are loaded as memory mapped files. They are loaded into physical memory, but since they are not modified after loading (usually) Windows doesn't back them by the page file, since it knows that it can just re-read them from their disk file - which is why they don't count towards the commit limit.

share|improve this answer
One small correction, shf301: You wrote "commit charge [...] only counts all physical memory that could be paged to disk." This should be written "only counts all virtual address space that could be paged to the pagefile." One, commit charge is a count of virtual, not physical, memory. Two, it is possible, even common, for memory mapped files to be mapped read/write. If a page that came from such a file is modified, then if it has to be paged to disk, it is written back to the file it came from, not to the pagefile. – Jamie Hanrahan Nov 15 '14 at 19:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .