First off, let us get a couple of things out of the way
- XP is a Virtual Memory Operating system
- There is nothing you can do to prevent virtual memory
- There is nothing you can do to prevent paging in the NT kernel
No matter your configuration, with any given amount of ram, you can not reduce the amount of paging by adjusting any user interface in these virtual memory operating systems... you can redirect operating system paging, and you can circumvent virtual memory strategy, but you cannot reduce the amount of paging in the NT family of kernel.
To elaborate;
We have to realize that paging is how everything gets brought into memory in the first place!... it's quite obvious that anything in memory either came from your disc, or will become part of your disc when your work is done.... to quote the Microsoft knowledge base:
No matter what your system configuration is, Windows NT will create and use a paging file... Windows NT REQUIRES "backing storage" for EVERYTHING it keeps in RAM. If Windows NT requires more space in RAM, it must be able to swap out code and data to either the paging file or the original executable file.
Here's what actually happens:
Once information is brought into memory, (it must be paged in), the operating system will choose for that process the memory reclamation strategy... one form of this memory reclamation (or paging, so to be clear)... the kernel can mark to release or unload data without a hard write, the os will retrieve said information directly from the .exe or the .dll that the information came from if it's referenced again.
Accomplished by simply "unloading" portions of the .dll or .exe, and reloading that portion when needed again... nice.
Note: For the most part, this paging does not take place in the pagefile, this form of paging takes place within the direct location of the .exe or .the dll
The "paging file" is another form of paging... this form of paging is, on that point, to provide space for whatever portion of virtual memory has been modified since it was initially allocated... for instance,
IF it's not in RAM at the moment,
AND it isn't backed up by any other file, then it's in the pagefile. (other data can be in the page file as well, but these dati in particular)
See this?...modified information cannot have backing store to the original file or .exe's SINCE it's modified* ...this is obvious once told isn't it.
Different types of things are paged to different files. You can't page "private writable committed" memory to exe or .dll files, and you don't page code to the paging file.*
With this understanding we realize:
HAVING A PAGEFILE THAT DOESN'T MATCH THE RAM YOU HAVE IN USE WILL AT TIMES INHIBIT THE PAGING OF PRIVATE WRITABLE VIRTUAL ADDRESS SPACE AND FORCE THE UNNECCSARY UNLOADING OF POSSIBLY RECENTLY ACCESSED .DLLS AND .EXES!
You see now, in a situation as such, when memory needs to be reclaimed, you'll be paging and unloading the other things in order to take up the necessary slack you've lost by having a page file smaller then the memory in use, (the private writable pages can no longer be backed if you've taken away it's page file area.)
Affect?... Stacks, heaps, program global storage, etc will all have to stay in physical memory... NO MATTER HOW LONG AGO ANY OF IT WAS REFERANCED!!!.... this is very important for any given workload and ANY amount of RAM, since the os would like to mark memory available when it's not been called for a long time. You have impeded this strategy if you have a page file lower then the amount of ram in use.
The hits?...more paging or backing of executable code, cache data maps, and the like.. even though they were referenced far more recently than for arguments sake, the bottom most pages of a thread's stack....see?...these bottom most pages are what we want paged, not .exe's or .dlls that were recently referenced.
You thwart this good strategy when there is a smaller amount of pagefile then there is the amount of memory in use.
All memory seen under the NT family of OS's is virtual memory...there is no way to address RAM
directly!!
And so we see, if memory is in use, it has either come from the hardrive or it will go to the hardrive...THERE MUST BE HARDRIVE AREA FOR EVERYTHING YOU HAVE IN MEMORY...(self evident, isn't it).
Now, that's out of the way, let's go further:
When the operating system needs to claim memory, (because all memory is currently in use, and you are launching new apps, or loading more info into existing work)... the os obviously has to get the necessary ram from somewhere... something in memory will (must) be unloaded to suit your new work...no one knows what will be unloaded until the time comes, as xp will unload the feature that is least likely to come into use again.
Memory reclamation in xp even goes further then this to make the process as seamless as possible, using more algorithms then most can appreciate.
For instance, there is also a "standby list" ... when information hasn't been used in a while, but nothing is claiming the memory as yet,...it becomes available, both written on disc, (possibly the pagefile), and still in memory...oh, did I forget to say? ALL AT THE SAME TIME! ('till the memory is claimed)....sweat!!!...if this information is called before the memory were claimed by a new process, it will be brought in without needing anything from the hardrive!...this is what's known as a “soft fault"...memory available and loaded, also at the ready for new use at the same time!
Why so much trouble with today's amount of ram?
You have to realize; most programs are written with the 90/10 rule - they spend 90% of the time bringing 10% of their code or data into use by any given user. The rest of a program can (should) be kept out on disk...this will obviously make available more physical memory to be in use for other more immediate and important needs...you don't keep memory waiting around if it's not likely to be used, you try to have your memory invested in good purpose and function...the unused features of these programs will simply be paged in (usually from the .exe) if they are ever called by the user...HA!!!...no page file used for this paging...unloading and reloading of .exe's and .dlls.
To sum everything up;... If you are not short of hardrive space, reducing the size of the page file lower then the default is counter productive, and will in fact impede the memory strategies of xp...here's why;
Mapped" addresses are ranges for which the backing store is an exe, .dll, or some data file explicitly mapped by the programmer; (for instance the swap file in photo shop)..
"Committed" addresses are backed by the paging file.
None, some, or all of the "mapped" and "committed" virtual space might actually still be resident in the process address space ...simply speaking, this means that it's still in RAM and reference able without raising a page fault.
The remainder (ignoring the in-memory page caches, or soft page faults) have obviously got to be on disk somewhere. If it's "mapped" the place on the disc is the .exe, .dll, or whatever the mapped file is...if it's "committed", the place on the disc is the paging file.
Why Does The Paging File Need To Be Bigger Than The Information Written To It ?
This is simplest to explain using the following analogy;
If you were to look to any 100% populated apartment building in Manhattan, you would see that at any given time throughout the day, there are less then 25% of the residents in the building at once!
Does this mean the apartment building can be 75% smaller?
Of course not...you could do it, but man would that make things tough...for best efficiency, every resident in this building needs their own address...even those that have never shown up at all need their own address, don't they...We can't assume that they never will show up, and we need to keep space available for everybody.
512 residents will need 512 beds...plus they will need room to toss and turn.
For reasons similar to this analogy, you couldn't have various memory sharing their virtual address could you?
Once again, we repeat, it's necessary to have at least as much page file for the amount of ram you have in use.
Let's move on
!!!!!!!!!!!!!!!!!!!! IMPORTANT!!!!!!!!!!!!!!!!!!!!
ONCE THE PAGEFILE IS CONTIGUOUS, IT CANNOT BECOME FRAGMENTED ON A HEALTHY DRIVE.
THIS INCLUDES PAGE FILES THAT ARE "DYNAMIC"
Any "expert" that has told you the page file becomes fragmented due to "expansion" has an incomplete understanding of what the page file is, what the page file does, and how the page file functions.
To make this as simple as possible, here's what actually happens, and exactly how the "fragmented pagefile" myth got started;
First, we need to point out that the page file is a different type of file then most of the files on your computer...the page file is a "container" file....most files are like bladders that fill with water...they are small, taking no space on the hardrive at all until there is information written...the boundaries of the file will form and change as information is written, the boundaries grow, shrink and expand around and in between the surrounding area and the surrounding files like a balloon or bladder would.
The page file is different...the page file is not like a bladder, it's like a can or container...even if nothing is written to the page file, it's physical size and location remain constant and fixed....other files will form around the page file, even when nothing at all is written to it. (once the page file is contiguous.)
For instance, suppose you have a contiguous page file that has an initial minimum of 256mbs....even if there is absolutely nothing written to that page file, the file will still be 256 mbs big...the 256 mbs will not move in location on the hardrive...nothing but page file activity will enter the page file area (obviously)...with no information written to the page file, it is like an empty can, which remains the same size whether it's full or empty.
Compare this again to a common file on your hardrive...these files behave more like a blatter then a container...if there is nothing written to a common file, other information will form in proximity...this will affect the final location of these common files...not so with the page file
Once you make the page file contiguous, this extent will remain identical on a healthy drive...even if expansion is invoked.
Here's how the "fragmented page file" myth due to dynamic page file got started;
Suppose for arguments sake, your computing episode requires more virtual memory then your settings accommodate.
The operating system will try to keep you working by expanding the page file...this is good...if this doesn't happen, you will freeze or slow down stall or crash.
Now, it's true, the added portion of the page file in this situation is not going to be near the original extent...you now have a fragmented page file, and this is how that "fragmented page file due to expansion" myth was started...HOWEVER IT IS INCORRECT...simple to see also...the added portion of the page file is eliminated on re boot...the original page file absolutely has to return to the original condition and the original location that it was in when you re-boot...If the page file was contiguous before expansion, it is absolutely contiguous after expansion when you re-boot.
What Causes the Expansion of a Page file?
Your operating system will seek more virtual memory when the "commit charge" approaches the "commit limit"
What does that mean?...in the simplest terms, when your work is asking for more virtual memory, (commit charge) then what the operating system is prepared to deliver. (commit limit)
For the technical terms, the "commit charge" is the total of the private (non-shared) virtual address space of all of your processes...this will exclude however all the address that's holding code, mapped files, etcetera.
For best performance, you need to make your page file so large, that the operating system never needs to expand it...that the commit charge, (virtual memory requested) is never larger then the commit limit (virtual memory available)...or in other words, your virtual memory must be more abundant the operating system will request. (soooo obvious, isn't it)....this will be known as your initial minimum.
Then, for good measure you need to leave expansion available to about three times this initial minimum, and thus, the operating system will be able to keep you working (at no price whatsoever) in case your needs grow...ie, you start using some of those very sophisticated programs that get written more and more every day...or you create more user accounts, (user accounts invoke page file for fast user switching) or for whatever, there is no penalty leaving expansion enabled.
NOW YOU HAVE THE BEST OF BOTH WORLDS...a page file that is static, because you have made the initial minimum so large the os will never need to expand it...and, expansion enabled just in case you are wrong in your evaluation of what kind of power user you are or become.
USUALLY THE DEFAULT SETTINGS OF XP ACCOMPLISH THIS GOAL...and most users do not need to be concerned or pro active setting their virtual memory...in other words, leave it alone.
HOWEVER, SOME USERS NEED TO USE A HIGHER INITIAL MINIMUM THEN THE DEFAULT...these are the users that have experienced an episode where the operating system has expanded the page file, or claimed that it is short of virtual memory.
NO USER THAT IS NOT SHORT OF HARDRIVE SPACE SHOULD EVER LOWER THE DEFAULT SETTINGS OF THE PAGEFILE.
Fact!