Let me quote him from his Windows Internals book:
And those sections are used everywhere. No applications would work without the page file, if your statement was true.Because Windows can run with no paging file, page-file-backed sections might in fact be
“backed” only by physical memory.
Windows has a memory manager that handles the memory requests from the applications. Since the physical memory can be limited and ran out of rather quickly depending the size of the memory, the page file has become a necessity for multitasking. This has been more of a concern in the past; however, application people with their appetite for more virtual memory, they ensure that this is always an issue...
The sum of the physical memory and the pagefile is the virtual memory. This can be large in the case of the 64-bit OS, but applications can receive 4 GBs of that if they can use the Address Windowing Extensions, or AWE API. Otherwise apps are getting 2 GBs as you've mentioned.
Quote from the link above:
"The size of the virtual address space is not changed. 32 bit addresses are still used. What is done is that different RAM pages are mapped into application specified virtual addresses. Although exercising this mapping has an overhead, since the mapped pages are in RAM, the overhead is considerably less than reading and writing to a disk file."
That sounds to me that there is some performance benefit for disabling the page file that forces using the physical memory only. While it may sound so, there's no guarantee that it is so. And certainly, some applications that call for more virtual memory than windows has available will tank, no question about that.
On an individual level and non-critical systems, such as home workstation, disabling the pagefile is a personal preference. I certainly would not do it for any servers, or even for my work desktop/laptop. On my home machine the worst thing can happen is one reboot, if the out of memory error shows up...
Well, not necessarily - if an applications maps a file section and tracks it, and then said application gets a return value that it doesn't like (or calls to grab that section from a paging file that doesn't exist, etc), the application can still crash. That's the whole point - why some apps "do not like running with no paging file". I didn't mention it's the memory manager's fault, did I?. No, it's poor coding, usually, but that doesn't mean it's not possible. It's not a rumor, otherwise it wouldn't be possible. Poor design can sometimes mean you run with a paging file to satisfy a poorly-written app that makes assumptions, because it's easier (usually) than getting the vendor to rewrite portions of the application, especially when those applications are old and decrepit, no longer supported/maintained, etc.
I'm not confused, just a realist (I know how the memory manager works pretty well). Mark is right, but he also speaks about a perfect world where application developers don't do stupid things. You and I should both know that isn't where some of these applications live
cluberti, you argued that an application could pass a flag to a memory allocation function and fail if there is no page file.
That is the argument that is not true. You cannot call any allocation function and have it fail just because there is no page file. If it fails because you are low on memory then that is another matter and is irrelevant to this discussion.
I say irrelevant, because we have already made it clear that if your commit limit is not enough to accommodate your needs - then of course you need a xxx MB large page file.
OK, fail is a bad word without context, although that ultimately is what happens. Note that it's not the memory manager failing, it's the app making the API call and then being stupid based on the return - I suppose I could make it clearer next time.
I have it set to default, I have more than enough disk space. Soo, it takes 6054 MB.
I look at the page file usage in SIW. I've seen it go to 0. Yes, zero, not capital O.Usually it's in the vicinity of 100 MB.
Therefore I say - leave it alone. Windows does a good job managing it. What's the point of 'tweaking' it other than empty enjoyment of looking at your UNUSED free space.
The link and quote is about AWE. AWE is not about the page file, but about addressing physical memory in chunks (a chunk is a "window" that points to your physical ram). It is an API that can be used to address huge amount of physical ram - even if your virtual address space is limited. It is not used much.
I believe, unless I'm forgetting something really old, that the only Microsoft server product to use AWE is/was SQL server, and given Win2008 R2 no longer has a 32bit variant available this won't continue once older OSes are dropped. Oracle used to have versions of their server products that used this as well (and I assume there are of course others), but it is indeed pretty rare.
Running with no paging file on a large system is fine, as long as you're sure your usage patterns will never try to commit more VA to RAM than you actually have available. For home use, go for it - for servers, be really careful. For any sort of production use, don't do it. It's not worth the possible BSOD, at least in my opinion. You don't want that to be the reason some really important machine crashes in the middle of something that absolutely can't be lost, etc.
One interesting note that best described by pictures...
Just a short test with the pagefile disabled shows this for page faults monitoring:
There are still page faults and pages per second, both can max out the 500 chart limit, but no writes. Enabling the pagefile, system manage, for two of my HDD's shows this:
Granted the period had been short, but there was a write even if the memory utilization has never reached 50% with most of my programs running.
Anyone knows why Windows keep "paging" if there's no pagefile? Unless it uses the "cashed memory" for this purpose, but shouldn't it show writes as well?
At idle, my system has this physical memory utilization:
Since I don't use many programs at once, the available memory seemed more than enough for programs. I still believe that, but need to look at what are these pages for, if there is no write...
Quote
