Windows – How I tell Windows 7/8/10 to be less aggressive in making copies of RAM to pagefile

This is a micro-optimization. The point is that there's no reason to do it, in anything resembling normal operation. It could easily hurt you if your usage pattern changes.

In specialized cases it might make sense, such as if there is no local writeable disk.

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.