So if the "page fault happens when the OS tries to access a page that is not in memory", and that page is not in the page file either because we said there was no page file, where is it then? Cheers, - jahman.

It was obviously requested for the first time, so in the disk

I'm testing the PMDG NGX in PNW where I consistently run out of VAS with extreme settings (75% traffic, maxed out scenery and very dense autogen)Iowering those a notch proved to be stable (50% traffic, very dense scenery and dense AG), now I disabled the page file with these same settings and got a CTD:

Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000Exception code: 0xc0000005Fault offset: 0xfffbfffeFaulting process id: 0x11c4Faulting application start time: 0x01cc5675b4287d9eFaulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exeFaulting module path: unknownReport Id: 3e7b1f75-c26c-11e0-a902-f50a051b37ce

Might be a coincidence, will need to test that more thoroughly but I'm pretty sure that running FSX + NGX without a page file is a recipee for disasterOh, and performance is apparently unaffected

It was obviously requested for the first time, so in the disk

When the page was requested for the first time, it's created in physical RAM. No page fault here, just a malloc. Don't confuse a page with a page fault! BTW, I did say the page file is required by apps that require memorydumps after a crash. Cheers, - jahman.

When the page was requested for the first time, it's created in physical RAM. No page fault here, just a malloc. Don't confuse a page with a page fault! BTW, I did say the page file is required by apps that require memorydumps after a crash. Cheers, - jahman.

This "page fault" meaning thing is irrelevant for the topic at hand, but I think it's you who is mixing concepts.My version:Malloc is a function for apps to pre-allocate VAS, it has no idea of what's going on in physical memory and it actually doesn't place any data in virtual memory either, so I don't think it can lead to a page fault at allPage faults happen in the OS' scheduler, never at an application level, and consist in pages accessed but not found in RAM. Whether that happened because the page was swapped to the page file or it never was there is a different story Assuming that disabling the page file is going to yield some benefits is assuming that the scheduler is going to try and swap out pages in an inefficient way even if there's plenty of RAM, and also that it will stop doing so if there's no page file (otherwise you'd get an app crash) Is that what you think is going on?

...Malloc is a function for apps to pre-allocate VAS, it has no idea of what's going on in physical memory and it actually doesn't place any data in virtual memory either, so I don't think it can lead to a page fault at all

Yes, that's exactly what I'm saying.

Page faults happen in the OS' scheduler, never at an application level, and consist in pages accessed but not found in RAM.

That's correct.

Whether that happened because the page was swapped to the page file or it never was there is a different story

.This is where we differ: A page fault is an interrupt (transparent to the app) that invokes an OS interrupt handler to read-in a previously swapped-out page from the page file. If a page was not previously swapped out, regardless of the reason, there is no page fault interrupt triggered. Of course if there is no page file in the first place, it goes without saying that no pages could have been swapped out, therefore you will not be having any page fault interrupts.

Assuming that disabling the page file is going to yield some benefits is assuming that the scheduler is going to try and swap out pages in an inefficient way even if there's plenty of RAM, and also that it will stop doing so if there's no page file (otherwise you'd get an app crash) Is that what you think is going on?

I'm not even getting into the benefits of having vs. not having the page file. No page file, no page faults. Cheers, - jahman.

This is where we differ: A page fault is an interrupt (transparent to the app) that invokes an OS interrupt handler to read-in a previously swapped-out page from the page file. If a page was not previously swapped out, regardless of the reason, there is no page fault interrupt triggered. Of course if there is no page file in the first place, it goes without saying that no pages could have been swapped out, therefore you will not be having any page fault interrupts.

I know you love Wikipedia ...I do too:

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, but not loaded in physical memory

http://en.wikipedia....wiki/Page_fault No page file involved. Simple as that

I'm not even getting into the benefits of having vs. not having the page file. No page file, no page faults.

Like Gary said, look at Process Explorer and see if there are no page faults without a page file. It doesn't look like you get any significant paging either once you enable it, but it would be cool if PE had a logging option to see if there are more page faults with a page file. I'm willing to bet that 99.99% of the page faults are 1st time accesses

I know you love Wikipedia ...I do too: http://en.wikipedia....wiki/Page_fault No page file involved. Simple as that Like Gary said, look at Process Explorer and see if there are no page faults without a page file. It doesn't look like you get any significant paging either once you enable it, but it would be cool if PE had a logging option to see if there are more page faults with a page file. I'm willing to bet that 99.99% of the page faults are 1st time accesses

AFAIK, you are correct, in that each page has a status, and the page is only written to the page file if it is dirty. There is no write otherwise, instead on a page fault it is simply re-read from eg the image on HDD. scott s..

I know you love Wikipedia ...I do too:http://en.wikipedia....wiki/Page_fault

Yes, Wikipedia is a great resource!

No page file involved. Simple as that

No, the page file is not mentioned because it is implied: The article begins: "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, but not loaded in physical memory". So if the page is not loaded in physical memory, the implication is the page is on another type of memory, i.e. RAM. What other types of memory are there in a PC different from physical memory? Well, there's ROM (won't work as it can't be written to), there's CD/DVD/Blu-Ray (too slow for practical purposes), and then there's disk. So disk it is. And how does a disk store data? A disk stores data in files. And what do you call a file that contains memory pages? A paging file. Bingo! A paging file is so inherent to physical memory paging that the article doesn't even mention the page file! Note that for the purposes of this discussion, physical memory includes CPU cache memory. As the CPU runs there is constant activity whereby the hardware pages memory around automatically beween the L1, L2, L3 caches and RAM, but this is a different type of low-level CPU hardware paging unrelated to and independent from the software paging driven by the operating system that we have been discussing.

Like Gary said, look at Process Explorer and see if there are no page faults without a page file. It doesn't look like you get any significant paging either once you enable it, but it would be cool if PE had a logging option to see if there are more page faults with a page file. I'm willing to bet that 99.99% of the page faults are 1st time accesses

You can't have "1st time access" page faults, because prior to the first time access the page doesn't exist, so it would not have been swapped out to the page. Cheers, - jahman.

You can't have "1st time access" page faults, because prior to the first time access the page doesn't exist, so it would not have been swapped out to the page.

Ok, I think you're right (damn this thread! ). It was me confusing the application level with the VM manager's (did I say scheduler?) dutiesLooks like what PE displays as page faults include hard and soft page faults. Hard page faults cannot happen without a page file, but soft faults can indeed ocurr (or at least I think so)

Ok, I think you're right (damn this thread! ). It was me confusing the application level with the VM manager's (did I say scheduler?) dutiesLooks like what PE displays as page faults include hard and soft page faults. Hard page faults cannot happen without a page file, but soft faults can indeed ocurr (or at least I think so)

Yes, it's possible the PE is reporting something beyond just a page being read from the pagefile (i.e. a "hard" page fault). Glad we got this sorted out! :Big Grin: Cheers, - jahman.

Yes, Wikipedia is a great resource! No, the page file is not mentioned because it is implied: The article begins: "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, but not loaded in physical memory". So if the page is not loaded in physical memory, the implication is the page is on another type of memory, i.e. RAM. What other types of memory are there in a PC different from physical memory? Well, there's ROM (won't work as it can't be written to), there's CD/DVD/Blu-Ray (too slow for practical purposes), and then there's disk. So disk it is. And how does a disk store data? A disk stores data in files. And what do you call a file that contains memory pages? A paging file. Bingo! A paging file is so inherent to physical memory paging that the article doesn't even mention the page file! Note that for the purposes of this discussion, physical memory includes CPU cache memory. As the CPU runs there is constant activity whereby the hardware pages memory around automatically beween the L1, L2, L3 caches and RAM, but this is a different type of low-level CPU hardware paging unrelated to and independent from the software paging driven by the operating system that we have been discussing. You can't have "1st time access" page faults, because prior to the first time access the page doesn't exist, so it would not have been swapped out to the page. Cheers, - jahman.

Ok, I've been doing some reading on this.Actually it seems that you can have hard faults without a page file:There's something called file mapping views, that are pages in VM pointing to files in the disk (like dll's). Those pages can and will be loaded into the working set when needed, and offloaded (if unmodified) from memory by pointing the page in VM back to the disk (not the page file, the file's original location in the HDD) That means that without a page file, when the VMM decides it needs to page out for whaterver reason, if you have disabled the page file it won't be able to page out modified pages of the process' working set that might not be needed but can't be dropped because they're not backed anymore (being modified pages), or whaterever it would be best to page out at that moment, thus forcing the VMM to pick something else, like a file mapped page that can be dropped, but could very well be needed in memory in the near future. When that happens, you'll get a hard fault and the VMM will need to load those file mapped pages back into memory So actualy there's a good chance of hard page faults without a page file source

Not all the virtual memory that a process allocates counts toward the commit limit. As you've seen, reserved virtual memory doesn't. Virtual memory that represents a file on disk, called a file mapping view, also doesn't count toward the limit unless the application asks for copy-on-write semantics, because Windows can discard any data associated with the view from physical memory and then retrieve it from the file

Ok, I've been doing some reading on this.Actually it seems that you can have hard faults without a page file:There's something called file mapping views, that are pages in VM pointing to files in the disk (like dll's). Those pages can and will be loaded into the working set when needed, and offloaded (if unmodified) from memory by pointing the page in VM back to the disk (not the page file, the file's original location in the HDD) That means that without a page file, when the VMM decides it needs to page out for whaterver reason, if you have disabled the page file it won't be able to page out modified pages of the process' working set that might not be needed but can't be dropped because they're not backed anymore (being modified pages), or whaterever it would be best to page out at that moment, thus forcing the VMM to pick something else, like a file mapped page that can be dropped, but could very well be needed in memory in the near future. When that happens, you'll get a hard fault and the VMM will need to load those file mapped pages back into memory So actualy there's a good chance of hard page faults without a page file source

Dazz, with memory-mapped file access you don't use a page file because the file you are accessing is the page file for itself. Still, in either case for VM or memory-mapped files, no file (paging file for VM, data file for MMF) no paging! :Big Grin: Cheers, - jahman.

Dazz, with memory-mapped file access you don't use a page file because the file you are accessing is the page file for itself. Still, in either case for VM or memory-mapped files, no file (paging file for VM, data file for MMF) no paging! Cheers, - jahman.

Ok, no paging, but you can have hard faults, which completely defeats the point of disabling the page file. Actually "paging or no paging" is irrelevant if the VMM can still drop pages from memory without a page file (that is esentially the same thing as paging if you think of it) and those pages can easily be part of a dll or an exe file that the process will need back in memory shortly

Ok, no paging, but you can have hard faults, which completely defeats the point of disabling the page file. Actually "paging or no paging" is irrelevant if the VMM can still drop pages from memory without a page file (that is esentially the same thing as paging if you think of it) and those pages can easily be part of a dll or an exe file that the process will need back in memory shortly

You can rephrase it as much as you want, but the point still is that no page file, no virtual memory page faults! (And no memory-mapped data file, no file access page faults, but that's a separate subject.) Cheers, - jahman.

If you're going to play the "what I said was strictly semanticaly right, don't really care about the implications" card, let me remind you your initial statement

I'm not even getting into the benefits of having vs. not having the page file. No page file, no page faults.

And I don't know where you trying to go to. memory-mapped data file is the same thing as file mapping view