Ironically, Linux will occasionally use swap space (if enabled) when ram is not full to make the system run faster. If Linux feels that your system will be faster by pushing some old pages into swap to free up more space for file caches, then it will do so. Of course, being Linux it is all controllable - you enable or disable swap dynamically as you want, and can use the "swapiness" control to change the balance between freeing space for file cache, or minimising swap usage.
I certainly have no qualms about putting Linux swap files on SSDs.
The paging mechanism itself is not at fault, but other things Microsoft got wrong are working against it.
As someone else said, the paging statistics often are misinterpreted. If you look with, e.g., Process Explorer, quite often you'll often find that there is very little in the pagefile and, at the same time, loads of unused RAM ... and yet the disk is churning. At least on NT/2K/XP ... Windows 7 and 2K3 and later server editions have self tuning management and do a much better job (though they all still have the performance counter registry access issues).
The first issue is that Windows uses relocatable libraries as opposed to position-independent libraries. Because dlls are not position independent, when multiples instances are mapped at different addresses, there must be multiple copies of the code in memory (one for each base address). The most commonly used OS dlls have unique base addresses so the odds of multiple mapping are very low (though not zero), but language runtime and user written dlls all have the same default base addresses unless the developer deliberately rebases them. Non-OS shared dlls often place unnecessary memory pressure on Windows. Code is paged directly from executables, so the pagefile is backing only instance data, but having to page in code for different instances increases disk accesses.
The second issue, which interacts with the first, is that Windows does not have a unified file system cache, but rather it tries to be "fair" by reserving cache address space for each running process. By default, Windows will take up to 80% of RAM for file caching, so if you have the normal situation where a lot of processes aren't using their allotted space, a lot of your RAM may be going unused.
There is a free tool called "cacheset" which will change the per process file cache limits. Unfortunately cacheset does not change the default settings in the registry, so you have to run it each time you log in, but the tool can be command line driven so you can place it a startup batch file.
Cacheset, Process Explorer, and a bunch of other useful stuff are all available at
formatting link
There are a number of registry tweaks available for adjusting process/system RAM distribution and default file caching parameters. You can find these with the search engine of your choice.
AFAIK, you can run any version of Windows without a pagefile - given sufficient RAM. I haven't tried it with Win7 (or 8) yet, but I know from personal experience that it works in all the previous versions (including server editions).
I can only speculate as to why you couldn't make it work. Windows doesn't handle over-allocation of address space in the same way Unix and Linux does. Unix and Linux don't commit pages until you touch them, so you can do idiotic things like malloc 1.5GB in a system with 256MB of total VMM space. As long as you never touch the extra, you'll never have a problem.
But unless an application is deliberately written using VirtualAlloc() et al., Windows commits *all* pages of an allocation immediately. If there is no pagefile, the total of all the committed space has to fit into RAM, so if programs are grabbing more memory than they intend to use, you can easily have a problem.
Ok, I see your point. But deleting the file technically is different from telling Windows not to use it. After turning off paging and rebooting, the file - even if there - won't be used. You can confirm this by monitoring.
2K and above do make it hard to remove the file permanently. Once paging is disabled, the file isn't in use and you can delete it with no problem, but without the registry edit you refer to the system will recreate the missing file on every reboot.
The simplest thing for most people to do is to reduce the file to minimum size (2MB). After reboot, the file will be truncated and won't ever grow. Then just forget about it.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.