Windows 7

Magic... run away quick, change the subject, anything, but don't dwell.

Game set and match to magic then?

VulcanB2 wrote: Either way, what is the point you are trying to make and the conclusion you are coming to from the fact that "chaos" does no ensue on deletion of the physical file? The point I am making, and you don't understand, is that the system does not care if the file is on disk or not. It has no bearing on memory and whether the system will try to page it out or not. Clearly you're never going to understand this.

You are talking rubbish again I'm afraid. There is nothing really to understand about rubbish that I am not getting.

Again, stop skirting around the edge, your whole point was that it is somehow better to run without a page file under real conditions (not your imaginary unlimited memory scenario) which is why you switched it off. You are just posting diversionary fluff.

Okay, let's go back to the "point [you are] making" and that I apparently don't understand. Your experiment to show and prove that "the system does not care if the file is on disk or not".

You stated...

VulcanB2 wrote: Try this then (if you're brave enough): start MS Word (or FS if you want), then move the FS9.EXE executable someplace else. Tell me if Windows ever moans it disappeared whilst the app is running. ... Did you not get the point when I *DELETED* the FS9.EXE file with FS running? FS9.EXE was no longer "backed by a file on the HD" as you put it. Based on what you're saying, the system should have failed because when it killed FS9.EXE in memory to load other stuff (based on your description of how it works), oops - FS9.EXE wasn't on the HD to look at. ... As I demonstrated when I deleted the FS9.exe file - the file was no longer on disk for this behavior to work. If this is how it did work, deleting the FS9.exe file should have created chaos

Except, in reality, you never did delete the FS9.exe when it was running did you?

You just assumed that moving it or renaming it would prove the same point. Because (as I wondered earlier and later found out and verified myself) there is no worry about what happens with the pager trying to access this file that no longer exists because you are prevented from deleting the file in the first place.

Try it this time rather than assuming - you'll get a big fat dialog... "Cannot delete FS9: Access denied"

Reason why there are no issues when you move it or rename it is because the OS keeps tracks of the file so remains able to page out memory relating to it and page it back in from the file if required. FS9.exe was still "backed by a file on the HD" as I put it all along...

Now, let's move on to your issue with the fact that memory pages that are backed, i.e. those that have come directly from the hd in the form of an .exe (your fs9.exe for example) or .dlls etc are freed if required and then paged back in directly from the file. I have explained this several times.

In response to those explanations you have stated...

VulcanB2 wrote: See, you made the same mistake again. IT DOES NOT DO THIS. ... Where do you get this rubbish from???????? WHAT IS YOUR TECHNICAL SOURCE FOR THIS BAD INFORMATION???? ... You will note that NOWHERE in these notes does it say it drops data that *already* resides on the hard disk in the traditional sense of a program or user data ... No it isn't. Not at all. ... As should be clearly apparent to you by now, no reference is ever kept of which file data came from. The system doesn't know, and it doesn't care. ... Huh? Read my links again. Keep reading until you understand. ... I can only summize that the reason MM is avoiding answering my question and has failed to produce any technical articles countering my position, either in whole or in part, means I am indeed correct in my assertions.

VulcanB2 wrote: provide links to technical descriptions that substantiate your definitions from Microsoft please.

Okay, here we go then, how about...

For example, each application has an executable file that represents pages of executable code and resources for the application. These pages are swapped into and out of RAM, as they are needed, by the operating system. When a page of memory is no longer needed, the operating system relinquishes control over the page on behalf of the application that owns it and frees it for use by another. When that page becomes needed again, it is re-read from the executable file on disk. This is called backing the memory with a file, in this case, the executable file.

(emphasis mine)

and...

when a process starts, pages of memory are used to store static and dynamic data for that application. Once committed, these pages are backed by the system pagefile, similar to the way the executable file is used to back the pages of code.

and...

Memory used to represent pages of code in processes for Windows NT are backed directly by the application's executable module while memory used for pages of data are backed by the system pagefile.

and...

Both code and data are treated the same way in Windows NT—both are represented by pages of memory and both have their pages backed by a file on disk. The only real difference is the file by which they are backed—code by the executable image and data by the system pagefile.

From where? Microsoft Developer Network. http://msdn.microsoft.com/en-us/library/ms810613.aspx - memory mapped files. You should take a look.

Also points out the benefits of using a page file for sharing data between processes which can prevent "a waste of system resources". Nice big diagrams as well showing the page file as a key part of the overall memory management - strange that if it's not really that important and not needed as you say...

Also...

Yet, in Windows NT, not all pages of memory are backed by these pagefiles. Instead, Windows NT backs pages of memory that represent either code or memory-mapped files with the actual file they represent. This provides a substantial savings of disk memory by eliminating redundant information on the disk.

Same library, section detailing the virtual memory manager in Windows NT.

VulcanB2 wrote: I don't see performance being cited as a reson to keep it.

Strange, nothing there about the performance benefits of disabling the page file though...

Just to close with a few of your own statements...

VulcanB2 wrote: I see a lot of arguments without any facts to back them up.

VulcanB2 wrote: I still don't see any references to anything countering my position yet.

VulcanB2 wrote: Again, please study the link very carefully. You have a flawed understanding.

VulcanB2 wrote: Read my links again. Keep reading until you understand.

VulcanB2 wrote: I think the phrase I'm looking for here is "I've got you on the run".

I think we should call it a day there shouldn't we...

Apologies to all others for this and all the quotes here etc. Normal service will be resumed shortly...

VulcanB2 wrote: If the memory manager decides to release memory pages occupied  by code that is backed, i.e. .exe’s, .dll’s, etc., stuff that already exists on the disk, then yes it is just freed, unless the page has changed, there is no need to copy it to a page file (why would it need to, it already exists). When that page is required again it is simply paged back in, i.e. re-read from the file on disk, i.e. from the .exe, .dll etc. No it isn't.

[pantomime audience]Oh yes it is…[/pantomime audience]

As I demonstrated when I deleted the FS9.exe file - the file was no longer on disk for this behavior to work. If this is how it did work, deleting the FS9.exe file should have created chaos, regardless of whether the swap file existed or not.

What exactly did you demonstrate and conclude from this and how is this trying to prove your case that a page file isn't needed...?

Loading it and then removing the physical file is only going to cause a problem if the situation arises that the virtual memory manager decides to drop memory pages relating to FS9.exe and then tries to page them back in. Actually, since the file no longer exists I’m not sure if the pager will even permit those code pages to be released or, if a pagefile is present, whether it instead uses it for backing store of the pages moved out.
Either way, what is the point you are trying to make and the conclusion you are coming to from the fact that "chaos" does no ensue on deletion of the physical file? If the mm does release the memory pages and they remain unbacked then we hit an issue if it tries to page them back in. If instead they are instead now backed by the page file then we are fine unless we have turned the page file off in which case the memory pages cannot be paged out and therefore the strategies of the mm are reduced.

As should be clearly apparent to you by now, no reference is ever kept of which file data came from. The system doesn't know, and it doesn't care. All it does when it writes to the page file to clear some physical memory, is copy the memory location verbatim. That's it. What occurs to files on disk, it doesn't care.

Rubbish. Unbacked pages will have no physical reference because they don’t exist on disk. Backed pages will have since their pages are paged in from the .exe, .dll file etc. It obviously knows where it came from.

VulcanB2 wrote: OK, to ensure there is no confusion on my part: If I have a block of data from hard disk loaded into the memory [...] and then the system freed the memory to load something else, instead of copying this block of memory to the swap file, it simply "forgets" it, and overwrites this [...] memory with something else, and just loads the [...] bytes it just overwrote, off the hard disk again, should it require it? Am I understanding this correctly?

If the memory manager decides to release memory pages occupied  by code that is backed, i.e. .exe’s, .dll’s, etc., stuff that already exists on the disk, then yes it is just freed, unless the page has changed, there is no need to copy it to a page file (why would it need to, it already exists). When that page is required again it is simply paged back in, i.e. re-read from the file on disk, i.e. from the .exe, .dll etc.

I don't see performance being cited as a reson to keep it. It just says not to disable it. The reason not to disable is because if you have 128 Mb of RAM and tried to run FS, without a page file, FS would not even start as it would run out of memory.

Absolutely astounding logic there... “Well Mr President, the reason I pushed the big red button with ‘Do not push’ printed on it was because it didn’t say it would cause any harm...”
So the reason to not disable it is because there is no reason to do so and if you do you could have problems in some circumstances...? So why disable it...???

see why I said it was important to discuss the page file and performance from the point of view of UNLIMITED memory???

Winner of the grand prize in the ultimate copout competition 2009.  Explanation of theory by reference to an unobtainable quantity, brilliant!

I know that in reality it is impossible, but when discussing the benefits of disabling the swap file, by assuming unlimited memory, and the fact that the system will swap memory out ANYWAY despite having lots of spare memory (unlimited in our example) then obviously it has performance BENEFITS.

That's stupid. You'd have to have 4096 page files to make use of that!!!

Best regards,
Vulcan.

at least it gives the OS something to fallback on if I run out of physical memory.

Yes, if you run out of physical memory.

If you have plenty of physical memory, then disabling the swap file is not a problem. Further, it increases performance because like it or not, even if there is free physical memory (several hundred megabytes) Windows will still copy memory to the swap file!!! The result of this is if the system then tries to access memory that was swapped out, even if it is for 10 bytes, it has to make disk I/O and performance instantly suffers.

Sure if you have unlimited memory in that sense then you would see an improvement since you wouldn't be writing to the slower hard drives, however you'd still run out of memory eventually

Only if you were stupid to try and run the system to the limits and beyond. Memory is so cheap there is no excuse not to add more physical RAM if you regularly run out of physical memory (swap file enabled or not). You WILL see increased performance for doing so. It is best to have more memory than you will use (hence my choice to go for 4 Gb for Vista for example - I know I won't use more than this at the current time. If I do, I'll simply buy more RAM).

Some limitations:

32-bit OS can never ever address more than 4Gb of memory. Because of memory mapped I/O present in current computer systems that you or I run, this limit is further decreased (in my case, to 2.6 Gb as the rest of the upper address lines are used for addressing hardware, etc. and are unavailable for memory addressing).

The page file can not exceed 4096 Mb in size, and XP x86 will never acknowledge more than 4 Gb of physical memory.

Here is a question: if you have two page files, both 4096 Mb in size, will Windows use them up to the full 8 Gb available?

From your link:

http://support.microsoft.com/kb/555223

Let me clarify one important point:

Virtual memory is NOT the page file. It has nothing to do with it.

Best regards,
Vulcan.

Which in turn affects physical memory.

Microsoft wrote: Pagefile RAM is a limited resource, whereas virtual memory is, for most practical purposes, unlimited. There can be a large number of processes each with its own 2 GB of private virtual address space. When the memory in use by all the existing processes exceeds the amount of RAM available, the operating system will move pages (4 KB pieces) of one or more virtual address spaces to the computer’s hard disk, thus freeing that RAM frame for other uses. In Windows systems, these “paged out” pages are stored in one or more files called pagefile.sys in the root of a partition. There can be one such file in each disk partition. The location and size of the page file is configured in SystemProperties, Advanced, Performance (click the Settings button).

http://support.microsoft.com/kb/555223

As I've said before, I'd rather leave paging turned on, at least it gives the OS something to fallback on if I run out of physical memory.

You see the word VIRTUAL? Do you need a dictionary?

Of course disabling the swap file will affected VIRTUAL memory. Sheesh.

Virtual memory is but one small part of the overall scheme of memory management. You need to read the more general notes on memory management to understand this.

Best regards,
Vulcan.

I don't see performance being cited as a reson to keep it. It just says not to disable it.

The reason not to disable is because if you have 128 Mb of RAM and tried to run FS, without a page file, FS would not even start as it would run out of memory.

@Marmite: see why I said it was important to discuss the page file and performance from the point of view of UNLIMITED memory???

Best regards,
Vulcan.