Ok, this is it. Jahman, you don't understand how Virtual Memory works. Period.

If the process modifies an MMF page that page is written back to the MMF, and not to the page swap file

The modified pages are writen back to disk where the view was created to point to. But the VM section is there all along. When there's a page fault related to a MMF view, it's a Virtual Memory page fault (that's actually redundant since you can't have page faults with no Virtual Memory involved) because it's a page in Virtual Memory that can't be found in RAM, just like any other page fault happens, by definition

Without a virtual memory swap file there can be no memory vrtualization, thus no virtual memory page faults"

This is laughable. Go back to the basics please

Ok, Dazz, you are confusing the MMF itself with the window the VMM uses to access the MMF, as I explained in my previous post. I also gave you a specific question to answer, which you didn't, and now you just take isolated statements from my posts. That won't fly, so there's really no point continuing this exchange. Cheers, - jahman.

there's no window, no buffer, have a link that describes that "window" and how it works? I don't think so. I answered your questions one by one and I don't think I'm confusing anything (I can admit when I'm wrong, not like you)Take the time to read those links like I did please. Everything you need to learn is there

OK, dazz, Cheers, - jahman.

I wasn't too clear there. If each of, say, 40 processes running under a 32 bit OS did a MMF attach of the same 1GB file as shared, the same 1GB of memory will be shared in each of the 40 processes' virtual address space (AKA shared memory, the most efficient way to share data between processes). But if each of those process did the attach as non-shared, that 1GB file would literally be copied 40 times in memory, thus expending 40GB of virtual address space (which is completely doable in a 32 OS).quote from the above link:"Memory mapped files provide a mechanism for a process to access files by directly incorporating file data into the process address space."

Rod, hope you don't mind me quoting you here, and everyone else sorry for refloating this somewhat old thread, but I have a question for you please, since you're a pro.Seems that an argument commonly used to back up the theory of getting the pagefile in a RAM disk, or disabled altogether increases performance is that Windows and some programs tend to use the pagefile even when there's plenty of RAM available, so they assume resources are not being handled properly.I did a quick google search and found thisSo it looks to me like programs can use the paging file to share data across different processes and this is a perfectly legit think to do (or is it?)I'm guessing those file mapping objects are page-file backed for persistsnce, and disabling the paging file may well force them to crash, or some unpredictable behavior, while moving the pagefile to RAM means that you have no persistance anymore (apart of the rest of potential negative effects already mentioned)Long story short, it appears to me that not only you can have hard page faults without a page file, also assuming that the page file is there only to page out stuff when there's not enough memory is a misconception and not a valid argument to disable the page fileSo my questions are:Is this correct?Is this page file usage common/acceptable practice?Does this apply to all/some/latest Windows versions?Any other posible legit uses of the page file apart of this one? (if this one is legit)Thanks for your input

Edited February 25, 201214 yr by dazz

I don't really understand your agenda here dazz. But anyways....A physical RAM memory page is "swapped out" to the paging file only as a last resort in the event there are NO available physical RAM pages remaining when one is needed elsewheres. The selection of the page to be swapped uses an algorithm based on how active the pages' use has been, i.e. it selects pages that haven't been used recently.A process (i.e. program) has a maximum number of physical RAM pages it can use, its working set max quota; if it exceeds this limit a page will be freed to compensate, but it won't necessarily be swapped out unless another process or the OS needs it. This freed page can be quickly brought back into the process's working set if it was not swapped out. A process starts off with its minimum quota working set and it'll grow the working set pages by either implicitly page faulting them in (which is NOT a bad thing) or by explicitly asking the OS to grow the working space. This page fault may incur a disk access if the faulted page needs another chunk of "code" from a binary file to keep executing, but this in not considered a swap operation (nor a bad thing). There are also OS calls that allow a process to load and lock all its executable pages into RAM.The working set quota is defined by the amount of RAM which the computer has; more RAM means bigger working sets and fewer "soft swaps". Also more RAM means less chance of runnnig out of available RAM, which in turn means fewer pages swapped out to the paging file. From all this, it is obvious that using a traditional RAM disk as a system paging file is completely counter productive (which is nice way of saying completely stupid). Deleting the swap file all together is also a bad idea since it could lead to less efficient OS use of RAM resources. Consider: the OS also uses pages which age and can be swapped out, which it'll gladly do for a program which needs that RAM now. If it could not swap out the page, it'll have to either have to somehow take the effort dismiss that page's info (and recreate later if necessary) or cause a OOM error for the requesting program.So it comes down to this: if you are not heavily multitasking and got 4GB+ of RAM, the chances your app "swaps out" are almost nonexistant; and the swap file is your friend, as noted above. BTW, OS designers have put decades of effort into efficient use of memory resources and they DO know what there are doing.And if you want more details, study everything under this link: http://msdn.microsof...5(v=vs.85).aspxEdit: remove SSD comments that were off base...

Edited February 28, 201214 yr by TheFamilyMan

I don't really understand your agenda here dazz. But anyways....A physical RAM memory page is "swapped out" to the paging file only as a last resort in the event there are NO available physical RAM pages remaining when one is needed elsewheres. The selection of the page to be swapped uses an algorithm based on how active the pages' use has been, i.e. it selects pages that haven't been used recently.A process (i.e. program) has a maximum number of physical RAM pages it can use, its working set max quota; if it exceeds this limit a page will be freed to compensate, but it won't necessarily be swapped out unless another process or the OS needs it. This freed page can be quickly brought back into the process's working set if it was not swapped out. A process starts off with its minimum quota working set and it'll grow the working set pages by either implicitly page faulting them in (which is NOT a bad thing) or by explicitly asking the OS to grow the working space. This page fault may incur a disk access if the faulted page needs another chunk of "code" from a binary file to keep executing, but this in not considered a swap operation (nor a bad thing). There are also OS calls that allow a process to load and lock all its executable pages into RAM.The working set quota is defined by the amount of RAM which the computer has; more RAM means bigger working sets and fewer "soft swaps". Also more RAM means less chance of runnnig out of available RAM, which in turn means fewer pages swapped out to the paging file. From all this, it is obvious that using a traditional RAM disk as a system paging file is completely counter productive (which is nice way of saying completely stupid). Using a SSD for the system page file is also of serious questionable value (unless your money grows on trees, then sure...why not). Deleting the swap file all together is also a bad idea since it could lead to less efficient OS use of RAM resources. Consider: the OS also uses pages which age and can be swapped out, which it'll gladly do for a program which needs that RAM now. If it could not swap out the page, it'll have to either have to somehow take the effort dismiss that page's info (and recreate later if necessary) or cause a OOM error for the requesting program.So it comes down to this: if you are not heavily multitasking and got 4GB+ of RAM, the chances your app "swaps out" are almost nonexistant; and the swap file is your friend, as noted above. BTW, OS designers have put decades of effort into efficient use of memory resources and they DO know what there are doing.And if you want more details, study everything under this link: http://msdn.microsof...5(v=vs.85).aspx

Thanks Rod, but I'm the other guy the one against disabling the page file or putting it in a RAMDisk.I know how working sets are trimmed and pages can be sent to the Standby list if the working set grows too big, and those peges will only soft fault if referenced again, also heard of virtual locks (that's actually what most RAMDisk drivers do to build their volumes)I was only trying to confirm if it's true that the pagefile can be used for things other than paging and crash dumps, if it's a common and good practice to share data using CreateFileMapping:

To share data, multiple processes can use memory-mapped files that the system paging file stores

http://msdn.microsof...v=vs.85%29.aspxI keep hearing/reading people claiming that Windows and applications use the paging file even when they have plenty of RAM, and that must be because they are poorly designed or programed. I don't buy that, so I simply looked for something that might explain why they do that.So since for all I know you program at Windows level, thought I would ask you if that usage of CreateFileMapping to share data through the page file debunks the above statementAgain, if it's common/good practice, and if you know of other scenarios where using the paging file is fineThanks again for your input

Edited February 28, 201214 yr by dazz

What CreateFileMapping() does is load the file contents into phyisical RAM pages, which are then memory mapped into the processes working set. Other programs that use CreateFileMapping() with the same file will memory map the same physical pages into their working set (provided the mapping was set 'shared', otherwise a different set of RAM pages will be used). In the 'shared' situation, program A writes a value to a location in the mapped file and program B sees the value of that write immediate since its the same physical RAM location (hence the name 'shared memory'). Also, the file that was mapped is the swap area for the physical pages mapped; the system page file is not used.One detail ommitted from my lecture was that Windows sort of does always use the swap file, in that it allocates swap file space for all active physical pages and background caches those pages' contents to the swap file in order to make the potential swap out operation as fast as possible. Note the use of 'background' here, it's of very low priority. But yes, for the ultra paranoid this does take up CPU cycles, but only ones in which usually nothing of any value is happening anyways.Also, my comment about SSD drives was a bit thick. If all you have is an SSD drive, it's obvious you got to use it for the page file. If you are using SSD for your system drive and got the space to spare its worth using for system paging.

Edited February 28, 201214 yr by TheFamilyMan

Also, the file that was mapped is the swap area for the phsical pages mapped; the system page file is not used.

Ok, I thought that

The first process creates the file mapping object by calling the CreateFileMapping function with INVALID_HANDLE_VALUE and a name for the object.

using an INVALID_HANDLE_VALUE means that there was no file explicitly, so that was why the paging file was needed. Thought it was used to share data temporarily, that was in no file, and needed to be pagefile backed or something.

One detail ommitted from my lecture was that Windows sort of does always use the swap file, in that it allocates swap file space for all active physical pages and background caches those pages' contents to the swap file in order to make the potential swap out operation as fast as possible. Note the use of 'background' here, it's of very low priority. But yes, for the ultra paranoid this does take up CPU cycles, but only ones in which usually nothing of any value is happening anyways.

Great stuff, thanks again Rod, that's very interesting

Edited February 28, 201214 yr by dazz