Windows – Commit Charge < Physical Memory

Commit charge is basically the maximum potential pagefile usage. It is not related to the RAM.

Windows basically addresses memory into the pagefile before any applications uses it based on current pagefile usage. The commit charge doesn't reflect current memory usage, but reflects how much memory Windows is current addressing in the pagefile.

The Windows Task Manager utility, in its Performance tab, shows three counters related to commit charge:

• Total is the amount of pagefile-backed virtual address space in use, i.e., the current commit charge. The corresponding performance counter is called "Committed Bytes".
• Limit is the maximum possible value for Total; it is the sum of the current pagefile size plus the physical memory available for paging (this excludes RAM that is assigned to non-pageable areas). The corresponding performance counter is called "Commit Limit".
• Peak is the highest amount that the total commit charge has reached since the computer was last rebooted.

The commit charge increases when any program is opened and used, and goes down when a program is closed. It will also change when already-running programs allocate or free private virtual memory; for example, with the VirtualAlloc and VirtualFree APIs.

The commit limit may be increased by either creating additional pagefiles or, if pagefile expansion is enabled, by expanding an existing one. The operating system will expand the pagefile automatically, if possible, when the total commit charge approaches the limit. In such an event a popup window will be displayed stating that "The system is running low on virtual memory."

Some more information is available in Windows XP's documentation.

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.

and

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.