Windows 7

Your choice!

I still don't see any references to anything countering my position yet. You said at least one of the articles I linked to is counter to what I've said - please, quote which part.

I'm inviting you to prove me wrong, and even provided links, but all you ever post back is "you're wrong", but never substantiate it?? Does that have anything to do with the fact you can't prove me wrong, because it would actually undermine your position?

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

Best regards,
Vulcan.

VulcanB2 wrote: The mm will still drop backed pages and reload them as required. define "drop" define "backed pages"

"drop" as in drop from ram, release from memory etc. etc.

"backed pages" as said, stuff that already exists as physical files on the drive as opposed to unbacked stuff, i.e. memory pages that have changed, user changed stuff etc. that exist only in RAM (unless you have a page file)

and provide links to technical descriptions that substantiate your definitions from Microsoft please.

No, irrelevant. They are just words.

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

That's because you refuse to. You sound a bit like our friend kamikaze there... He was obsessed with conspiracy theories as well...

I'm inviting you to prove me wrong, and even provided links, but all you ever post back is "you're wrong", but never substantiate it?? Does that have anything to do with the fact you can't prove me wrong, because it would actually undermine your position?

Nope. The links you've provided have been mostly irrelevant to the issue here which is your insistence that running without a page file is better than with. You have yet to prove your case or provide relevant links that agree with this...

Your whole issue is that it is better to run without a paging file than with it, we don't have the fantastical gift of "unlimited memory space" unfortunately. None of your extensive posted links have even mildly pointed in that direction let alone prove it so rather than asking me and the others here following the advice of the designers, developers and experts who are actually responsible for the page file, its use by the memory manager and Windows as a whole, to prove why it's better to leave it there, give us your reasons why those people are wrong...

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

Ha, in your dreams...

You might be interested in this:

http://www.ece.cmu.edu/~ece548/handouts/05vmarch.pdf

Just to highlight it before you do:

Components that make virtual memory work include: • Physical memory divided up into pages • A swap device (typically a disk) that holds pages not resident in physical memory (that’s why it’s referred to as backing store as well) • Address translation – Page tables to hold virtual-to-physical address mappings – Translation lookaside buffer is cache of translation information • Management software in the operating system

A swap device (typically a disk) that holds pages not resident in physical memory (that’s why it’s referred to as backing store as well)

See the difference? I've personally never seen it referenced as a "backing store", but hey-ho - like I said, it's just terminology.

HOWEVER...

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.

All it does (and as I said it did), is it copies physical memory locations to the hard disk. Nothing more, nothing less.

You can write and argue with Prof. Philip Koopman if you like. You can find his contact details on the Carnegie Mellon University website. 

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.

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.

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.

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.

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

Best regards,
Vulcan.

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.

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.