Bob saves the thread once again..........thank goodness.

That's not how I understand it. Both Russinovich and the Wiki article you quoted state clearly that an MMF is a type of VM, and that makes sense as it's managed that way. The difference is that the MMF is not pagefile-backed, since the original file is used directly instead. But when a program using an MMF attempts to access an address located in a page not currently loaded in memory, a page fault does indeed occur, so it is possible to have a page fault in the absence of a dedicated page file. As to the original question, I do not place a pagefile onto my OS or FS SSDs, but instead manually establish the page file on an auxiliary HDD. Given 6GB of RAM to run a ~3GB app (FS) plus another 1 GB of system and related processes, the pagefile is rarely hit, but is available for a system dump or for a program that wants to see it there in case there might be a system dump.

100% percent in agreement, that's what I've been trying to say all along. The only clarification I will add for Dazz's benefit is that where you mention the MMF page faults is that those page faults are not related to virtual memory. This is important because the whole argument was whether or not you can have VM page faults without a page file and the answer is no, you can't (although you can hage MMF-related page faults). Thanks for your input, Scott and helping clear this up. To the rest of you, my apologies for failing to explain these concepts with enough clarity. Cheers, - jahman.

Page faults are by definition virtual memory events. It's absurd to suggest otherwise:

A page fault is a trap to the software raised by the hardware when a program accesses a page that is mapped in the virtual address space

http://en.wikipedia.org/wiki/Page_fault The thing is that you can have hard page faults without a page file and that they may actually happen as a direct result of disabling the page file

Page faults are by definition virtual memory events. It's absurd to suggest otherwise: http://en.wikipedia....wiki/Page_fault

That reference only talks about page faults on the context of virtual memory, so of course it will only talk about page faults... in the context of virtual emory! A tautology. Proof that MMFs are not part of virtual memory is in Win-32 you can use a max of 4 GBy virtual memory but you can of course simultaneously open, say, 10 MMFs of 4 GBy each. If MMFs were indeed part of VM this would not be possible because 4 GBy * 10 = 40 GBy >> 4 GBy 32-bit VAS!

The thing is that you can have hard page faults without a page file and that they may actually happen as a direct result of disabling the page file.

Yes, but (once again!) only due to MMF access and *not* due to virtual memory! Cheers, - jahman.

Ok, those pages outside the context of virtual memory are going to need a name, the jahman faults maybe?seriously jahmanMemory mapped files are mapped BYTE to BYTE. 34765 bytes in VM are mapped to 34765 bytes in disk. And memory mapped files still work with pages (in systems with paginated virtual memory) so typically 4KB pages, that reference 4KB in diskMemory mapped files use the whole Virtual Memory layer:

What Do Memory-Mapped Files Have to Offer?One advantage to using MMF I/O is that the system performs all data transfers for it in 4K pages of data. Internally all pages of memory are managed by the virtual-memory manager (VMM). It decides when a page should be paged to disk, which pages are to be freed for use by other applications, and how many pages each application can have out of the entire allotment of physical memory. Since the VMM performs all disk I/O in the same manner—reading or writing memory one page at a time—it has been optimized to make it as fast as possible. Limiting the disk read and write instructions to sequences of 4K pages means that several smaller reads or writes are effectively cached into one larger operation, reducing the number of times the hard disk read/write head moves. Reading and writing pages of memory at a time is sometimes referred to as paging and is common to virtual-memory management operating systems.Another advantage to using MMF I/O is that all of the actual I/O interaction now occurs in RAM in the form of standard memory addressing. Meanwhile, disk paging occurs periodically in the background, transparent to the application. While no gain in performance is observed when using MMFs for simply reading a file into RAM, other disk transactions can benefit immensely. Say, for example, an application implements a flat-file database file structure, where the database consists of hundreds of sequential records. Accessing a record within the file is simply a matter of determining the record's location (a byte offset within the file) and reading the data from the file. Then, for every update, the record must be written to the file in order to save the change. For larger records, it may be advantageous to read only part of the record into memory at a time as needed. Unfortunately, though, each time a new part of the record is needed, another file read is required. The MMF approach works a little differently. When the record is first accessed, the entire 4K page(s) of memory containing the record is read into memory. All subsequent accesses to that record deal directly with the page(s) of memory in RAM. No disk I/O is required or enforced until the file is later closed or flushed.

Note During normal system paging operations, memory-mapped files can be updated periodically. If the system needs a page of memory that is occupied by a page representing a memory-mapped file, it may free the page for use by another application. If the page was dirty at the time it was needed, the act of writing the data to disk will automatically update the file at that time. (A dirty page is a page of data that has been written to, but not saved to, disk; for more information on types of virtual-memory pages, see "The Virtual-Memory Manager in Windows NT" on the Developer Network CD.)

http://msdn.microsof...y/ms810613.aspx I'm not going to keep on arguing with you. You prefer to pull some ridiculous "paging outside VM" before admiting that you were wrong, not to mention that you don't even care post a single link (not that you would find anything that backs up such an statement)Those things strongly suggest you need to go back to the basics

...Proof that MMFs are not part of virtual memory is in Win-32 you can use a max of 4 GBy virtual memory but you can of course simultaneously open, say, 10 MMFs of 4 GBy each. If MMFs were indeed part of VM this would not be possible because 4 GBy * 10 = 40 GBy >> 4 GBy 32-bit VAS! Cheers, - jahman.

The above is absolute rubbish. I'm a software engineer by profession, and there is NO WAY that a 32 bit address space process can successfully memory map a 4GB file in its entirety, let alone 40GB (BTW, I've actually seen programs crash which attempted to do simular MMF operations). To say otherwise is complete ignorance. Sure, a program can open tens (or even hundreds) of files that are 10GB in size, or that several concurrently executing programs on a 32 bit OS can each attach one 1GB MMF such that their combined memory usage hits 40GB, but it's not the same thing. And BTW, as usual, Bob's advise is spot on.

The above is absolute rubbish. I'm a software engineer by profession, and there is NO WAY that a 32 bit address space process can successfully memory map a 4GB file in its entirety, let alone 40GB (BTW, I've actually seen programs crash which attempted to do simular MMF operations). To say otherwise is complete ignorance. Sure, a program can open tens (or even hundreds) of files that are 10GB in size, or that several concurrently executing programs on a 32 bit OS can each attach one 1GB MMF such that their combined memory usage hits 40GB, but it's not the same thing. And BTW, as usual, Bob's advise is spot on.

would that be different processes accessing a shared file or file view via the same handle, data which would not be part of their private section?

MMFs are not part of the virtual address space of the application. BTW, I agree 100% with what Bob said, as well as with what dazz is quoting, none of which contradicts what I'm saying. The fact remains that VM and MMFs both use paging algorithms implemented in the VMM, but MMFs are not part of the app's virtual memory. Period. End of story. And it doesn't matter whether you mat a 4 GBy MMF in it's entirety or not. The point is you have 4 GBy available per GBy and that the size of your MMF (one or many) does not reduce the size of your app's virtual address space is total proof that the MMF is not part of yirtual memory. It just can't be clearer than that. Cheers, - jahman.

MMF are entirely in Virtual Memory, they could not be anywhere elseAnd I'm out now

would that be different processes accessing a shared file or file view via the same handle, data which would not be part of their private section?

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). jahman, go read some and come back when you are educated: http://publib.boulde...dress_space.htmYour persistense conjures up the T word. 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."

Of course every file I/O has buffers in the process address space, how else could the process access the data in the file? But if an MMF is part of the process VAS as you insist, then how do you map a 4 GBy MMF into a 32-bit VAS? Do explain this and I'll shut-up. THe answer of course is you don't, because the MMF is outside the process address space and what the VMM does is brinf in MMF pages as needed into the process VAS, but none of ths activity has anything at all to do with the memory paging file, as the weiki page explains (and Bob also agrees with). One thing is virtual memory, the virtual address space, virtual memory paging and the swap file, and another is the MMF. Two different things, same algorithm, same manager. 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). jahman, go read some and come back when you are educated: http://publib.boulde...dress_space.htmYour persistense conjures up the T word. 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."

Exactly! actually Bert (thanks again Bert) already pointed out to me in this same thread you can have n processes taking up more that 4GB of total VAS. The 4GB limit is for individual processesSo jahman, your "proof" fails once again.

Of course every file I/O has buffers in the process address space, how else could the process access the data in the file? But one thing is virtual memory, the virtual address space, virtual memory paging and the swap file, and another is the MMF. Two different things, same algorithm, same manager. Cheers, - jahman.

No buffers. MMF's are mapped BYTE to BYTE as clearly stated in the wikipedia article you posted but never read (or understood)I/O Buffers in virtual memory LMAO... the jahman buffers

OK, forget buffers (wrong term), call it the window allocated by the VMM to access the MMF. Same difference. As for 1 or n processes, it doesn't really matter: You still need to explain how one Win-32 process accesses a single 4 GBy MMF if as you say the MMF is part of the processes VM. Go ahead, I'm all ears. Cheers, - jahman.

But if an MMF is part of the process VAS as you insist, then how do you map a 4 GBy MMF into a 32-bit VAS? Do explain this and I'll shut-up. THe answer of course is you don't, because the MMF is outside the process address space and what the VMM does is brinf in MMF pages as needed into the process VAS, but none of ths activity has anything at all to do with the memory paging file, as the weiki page explains (and Bob also agrees with).

Of course an MMF is part of the process VAS. You fail to understand that you don't need to map the whole file, that's what the views are for. Read the links we post please. You are limited by the 4GB process VAS limit in 32b, but you can still partially map files that are bigger than 4GB. http://msdn.microsoft.com/en-us/library/aa366546%28v=vs.85%29.aspx

To map the data from a file to the virtual memory of a process, you must create a view of the file. The MapViewOfFile and MapViewOfFileEx functions use the file mapping object handle returned by CreateFileMapping to create a view of the file or a portion of the file in the process's virtual address space. These functions fail if the access flags conflict with those specified when CreateFileMapping created the file mapping object.

If I understood it correctly (please Rod correct me if I'm wrong), you could even have several processes map 4GB of the file each as shared, and then access the whole file from any of the processes

Dazz, I understand exactly how the VMM handles MMF access. I said in my previous post the VMM maps MMF pages into a window inside the process' VAS, But the MMF itself is not part of virtual memory: If the process modifies an MMF page that page is written back to the MMF, and not to the page swap file. Can you agree with this? And if you agree, you will then realize that even if you can have hard page faults due to MMFs, you still can't have VM page faults without a swap file, which is the point of this (seemingly endless) discussion. Without a virtual memory swap file there can be no memory vrtualization, thus no virtual memory page faults, but yes you can still have MMF-related page faults. Cheers, - jahman.