If you turn the PF off Windows will still create one regardless and use it.
If you disable the paging file, then it really is disabled. Windows can run perfectly fine without one. The role of the paging file is so the system can write pages on the modified page list, which represent pages that have been taking out of a process working set because they aren't being accessed actively, but have not been saved to disk, out to the paging file.
If there is no paging file, those pages won't get written out to disk. While this will result in less memory being available for other purposes, it's not going to prevent Windows from functioning correctly. Does this mean you can disable the paging file without any issues though? Nope, not necessarily.
The paging file has an impact on something called the system commit limit. This represents the maximum amount of committed virtual memory, which must be backed by physical memory or stored in the paging file, processes can allocate at any one time. The limit is therefore the sum of (most of) physical memory plus the size of the paging file(s). The commit limit needs to be large enough to accommodate your workloads system committed virtual memory requirements. If it isn't, your processes will be unable to allocate the virtual memory they want and will fail to run correctly.
The best way to monitor how much system commit your workload requires is by using
Process Explorer. If you open the 'System Information' window of process explorer and select the memory tab, take a look at the 'Commit Charge (K)' section.
Commit Charge (K):
- Current - This represents the amount of committed virtual memory processes have currently allocated which must be backed by physical memory or stored in the paging file.
- Limit - This represents the amount of committed virtual memory processes can allocate at any one time and is the sum of most of physical memory and the size of the paging file(s).
- Peak - This represents the total amount of committed virtual memory processes have allocated since the system booted which must be backed by physical memory or stored in the paging file.
To determine how large the paging file needs to be on your own system, once you have attained your maximum workload, take note of the 'Peak' commit charge. The difference between that value and the amount of physical memory of the machine is the size of the paging file which you will need to support your workload.
For instance, if your machine has 4GB of physical memory and your workload requires 6GB of system commit, you would need a paging file of at least 2GB to support it. This should be the bare minimum for the initial size of the paging file. You would want to add extra onto that value to give yourself some breathing room. If you are interested in crash dumps, make sure it's large enough to accommodate them as well.
You could then set the maximum size to double that value. Some people would suggest setting the initial and maximum size to the same value to prevent the paging file from changing in size. The paging file will only grow when the current commit charge reaches the initial system commit limit. It will grow right up and till it has hit it's maximum size, assuming there is a demand for it. If the paging file expanding and contracting is something that concerns you, as long as the initial allocation is sufficient, the paging file will never need to grow and simply serves as a safety net.
If you have enough physical memory to support your workloads system committed virtual memory requirements, you don't need a paging file and Windows will run absolutely fine without one under that workload. For example, your machine has 4GB of physical memory and your workload requires 2.5GB of system commit. However, there are a couple of disadvantages with running with no paging file. Firstly, there will be less memory available to you, and secondly, the system won't be able to generate crash dumps.
One other thing which is worth mentioning is regarding certain applications failing to run with no paging file. What appears to happen in a lot of cases which may give the impression that the application is failing to run due to no paging file is because the user has disabled it without any regard to how much system commit their workload requires.
There are certain applications which genuinely won't run if there is no paging file though. An example of this is Dawn Of War II. I wanted to gain a little insight regarding this, so I sent Mark Russinovich a message via his
blog, and this was his response.
Mark Russinovich said:
These apps could very easily be querying directly for the existence of a paging file and failing if one’s not present, based on the misconception that one is necessary.
Interestingly enough, if you add 'disablepagefilecheck' to the games shortcut, it will run absolutely fine with no paging file.
The very last thing which is worth talking about is why some people suggest disabling the paging file. Their argument is based on the fact that hard disks are slower than RAM. This ignores the following two points.
- How Windows manages physical memory.
- Disabling the paging file doesn't eliminate reading from disk.
Addressing the first point. When a private modified page is taken out of a process working set, it is moved to the modified page list. If the process then touches that page again, it will be soft page faulted back into it's working set. When the modified page list reaches a threshold, a thread called the ModifiedPageWriter wakes up and begins writing pages out to the paging file. The pages are then immediately moved to the standby page list, where they can be soft page faulted back into the process working set.
It's only when the memory manager gives the page which belonged to the original process to someone else will it have to retrieve it's data from the paging file. If it gets to this point, the fact the process needs to read from the paging file is going to cause a negligible impact on system performance. If that data was in your performance interest, it would already be resident in memory.
Touching upon the second point. Things like exe's and dll's are backed by their own location on disk, not the paging file. They will need to be read into memory from disk, which will therefore cause hard page faults. All that happens when you disable the paging file is the things which could be written there, the scenario where the data is written and read back in from disk is taken out of the equation.
If anyone is interested in Windows Memory Management, the videos below are well worth watching.
Mysteries of Memory Management Revealed, with Mark Russinovich (Part 1 of 2)
Mysteries of Memory Management Revealed, with Mark Russinovich (Part 2 of 2)
