Bad idea to disable pagefile?

[n7]

I've heard some programs do not function properly without it enabled, but i don't believe i have any of those.

Oh, & for those too lazy to click on my rigs link, i have 2 GB of RAM, & i've never used that much AFAIK, so that shouldn't be an issue.

 

[InlineFive]

I accidentally disabled mine for a week because I used the drive that it was on for Linux. The only thing that hiccuped was Photoshop.

 

[Nothinman]

Oh, & for those too lazy to click on my rigs link, i have 2 GB of RAM, & i've never used that much AFAIK, so that shouldn't be an issue.

If you have that much memory and you're not using it all then you're not using the pagefile either, so disabling won't buy you anything even if it does work.

 

[n7]

Ah okay....i just was under the impression that w/ pagefile enabled, Windows still often uses it, even when the RAM is available.

I'm wrong i guess?

 

[jEnus]

n7, you are correct. If if there is RAM available, Windows will still use its page file if it is enabled.

 

[Nothinman]

n7, you are correct. If if there is RAM available, Windows will still use its page file if it is enabled.

No, it won't. The accounting provided to taskmgr and perfmon is wrong because it includes pagefile reservations which aren't actually in the pagefile yet and may never be.

 

[RichUK]

Buy another 2 gigs of RAM and then disable the page file totally, then you can deal with ?ns? access times instead of ?ms? access times Windows can only address 4GB?s of memory whether it be virtual or physical.

However im not sure what would happen if you disabled the paging file with only two gigs of RAM, then go and generate a need for more than 2 gigs of memory addressing to be utilised. Maybe It would crash who knows, I dont.

I think the paging file mostly optimises the physical RAM utilisation within Windows, as well as give you the ability to address to the full 4GB's of memory that 32bit windows is capable of. It optimises by prioritising what data is to be stored in the physical faster RAM, therefore generating maximum efficiency from the amount RAM installed. It then stores the less frequently accessed data in the PF, and ?SWAPS? the data to and from the RAM and HDD as required, hence the name ?Swap File?. If you are an avid gamer, and don?t use the PC for much other tasks, I would imagine disabling the PF would be ok in this scenario. However if you multi task you might want to keep the PF enabled.

 

[Nothinman]

Buy another 2 gigs of RAM and then disable the page file totally, then you can deal with ?ns? access times instead of ?ms? access times

As long as you can deal with apps failing that need a backing store for anonymous mappings, modified read-only pages, etc.

Windows can only address 4GB?s of memory whether it be virtual or physical.

Wrong. With PAE Windows can access up to 64G of physical memory on 32-bit hardware, on 64-bit hardware Windows can access whatever the hardware can handle. IIRC Athlon64s do 40-bit addressing currently and Opterons do 48-bit, that's 1TB and 128TB.

 

[RichUK]

Yeah PAE is really for the server application, as current Athlon and opteron s939 compliant motherboards do not support more than 4Gb?s total capacity. So in his scenario PAE switch is useless. Not to mention the amount of strain that would be applied to the on die memory controllers, unless you use high density DIMMs on each channel.


No single socket Opteron or Athlon 64 can handle more than 4gigs, (or 2 gigs a channel). Current s940 Opteron's in multi socket motherboard configurations (2xx and 8xx series), use their additional hyper transport links to share the total motherboard memory capacity, this allows each processing core to be able to utilise a total of 16GB?s of physical memory, if using the high end 8xx series opteron processor in a four way configuration. AMD K8's can only access 4 gigs via their own on die DC memory controllers, and s940 opteron's can access more via their additional HT links. This increases the physical memory size for windows to address to (if using the PAE switch in the BOOT.INI).

Once again this is only for the server application, as only can most windows server OS?s utilise the PAE switch. Windows XP is capped at 4GB?s max memory (2GB dedicated kernel and 2GB dedicated for application data).

So this is not relevant in his scenario.

 

[Nothinman]

Yeah PAE is really for the server application, as current Athlon and opteron s939 compliant motherboards do not support more than 4Gb?s total capacity

PAE can be used by any app that wants to use it. And the limitations of the motherboard are irrelevant, the OS does support more.

So in his scenario PAE switch is useless.

So is any tweaking of the pagefile.

No single socket Opteron or Athlon 64 can handle more than 4gigs, (or 2 gigs a channel)

Yes they can, if you can afford a motherboard that will have enough slots to support the memory.

AMD K8's can only access 4 gigs via their own on die DC memory controllers, and the rest VIA their HT links. This increases the physical memory size for windows to address to (if using the PAE switch in the BOOT.INI).

How they get to the memory is irrelevant, the fact that the CPU and motherboard physically support >4G is the important part. And the PAE switch is only necessary if you're using 32-bit Windows.

Once again this is only for the server application, as only can most windows server OS?s utilise the PAE switch. Windows XP is capped at 4GB?s max memory (2GB dedicated kernel and 2GB dedicated for application data).

Again, any app that wants to make use of AWE to access more than 2G of VM can. The fact that MS limited Pro to 4G for no reason is irrelevant and AFAIK XP64 doesn't have this limitation.

So this is not relevant in his scenario.

And neither is disabling the pagefile, he already stated that he's not using the 2G that he has.

 

[RichUK]

Ok you must keep in mind that I am talking about his implementation of windows, which I can assume is Windows XP Home/Pro not a ?Datacentre? server edition OS/license.

Your arguments that the 32bit version of Windows (be it a server variant for PAE use), can support >4GB is fine this I do not dispute, as I am aware and work with this technology.

However there are hardware constraints, as no AMD server setup can support (at present time) more than 16GB?s of physical memory, and that is a given.

My quote

No single socket Opteron or Athlon 64 can handle more than 4gigs, (or 2 gigs a channel)

Your Argument

Yes they can, if you can afford a motherboard that will have enough slots to support the memory.

This is in fact false, if you are familiar with the K8 architecture you will be aware that the on die memory controller is not mature enough to support more than 4 gigs of memory per CPU. This is the memory controller?s physical constraint, and in practise will not support more than 2Gigs per channel 4 gigs total per processor. Also no motherboard supplies more than 4 DIMM slots to each individual processor with regards to K8. The motherboard can have a total of 16 slots but this is shared between 4 CPU?s in a 8xx series config, 4 slots to one CPU, and full support for total motherboard memory share due to the additional HT links, as previously explained.


I fear we have strayed off topic.

 

[n7]

Well, i've been running with it disabled since i posted this.

I just finished a nice gaming session, & there were no hiccups.

The real test will be when i do some encoding as i game.

 

[Nothinman]

Ok you must keep in mind that I am talking about his implementation of windows, which I can assume is Windows XP Home/Pro not a ?Datacentre? server edition OS/license.

You don't need Datacenter edition, infact you can only get that edition by ordering hardware with it, like an HP Superdome class machine. And as I said, XP64 Pro doesn't have that limitation.

However there are hardware constraints, as no AMD server setup can support (at present time) more than 16GB?s of physical memory, and that is a given.

Then how can Tyan sell 4 boards that say they support >16G memory on here?: http://www.tyan.com/products/html/opteron.html

 

[gaidin123]

On a work machine with 2GB of RAM I've had the pagefile disabled for several months with no real issues. For me if I leave firefox open for a while with a few tabs open and minimize it, XP seems to swap something to disk as when I unlock the box in the morning or just maximize firefox after a while it will sit there with the drive chugging. With the pagefile turned off there is no delay when focusing back on firefox.

Something similar happens with my rss reader. I don't know if XP is dumping stuff in the pagefile or if the apps cache pages/feedlists onto disk somewhere else when they're minimized but running without a pagefile has helped in this case.

I'm still not totally comfortable doing this but it's worked out well so far even though all the documentation I've read says to never turn it off.

Gaidin

 

[Markbnj]

No, it won't. The accounting provided to taskmgr and perfmon is wrong because it includes pagefile reservations which aren't actually in the pagefile yet and may never be.

That's true, but not necessarily the whole story. Windows considers its pagefile an extension of system ram, and the virtual memory manager treats actual ram and the pagefile essentially the same, with one key difference: when an application reserves storage without actually committing it, Windows will allocate those addresses from the pagefile. If the app later wants to commit that storage it will swap the reserved pages into ram.

All of this may not matter a hell of a lot if you have so much ram that Windows never uses it all, but it is important to note that many applications reserve much more storage than they actually use. For some apps, including some games like Bf2, this amount can run more than a gigabyte. In these cases the lack of a pagefile will force Windows to keep all allocated addresses in system ram, including storage allocated to programs that are running, but aren't doing much while you are playing your game.

 

[Nothinman]

That's true, but not necessarily the whole story. Windows considers its pagefile an extension of system ram, and the virtual memory manager treats actual ram and the pagefile essentially the same, with one key difference: when an application reserves storage without actually committing it, Windows will allocate those addresses from the pagefile. If the app later wants to commit that storage it will swap the reserved pages into ram.

It's not an extension of memory, it's impossible for data to be directly accessed inside of the pagefile. It's used as a temporary storage medium for data that doesn't have a backing store anywhere else. So pages that were read from binaries, shared libraries, etc and have no been modified will never be put in the pagefile because they can always be paged back in from the file on disk they originally came from. Pagefile reservations may or may not actually be put in the pagefile, even if they do cause some I/O to put the pages into the pagefile at some point they won't cause any performance changes. The amount of pages in memory that have no backing store is usually pretty small and with disks as fast as they are today writing a few MB/s here and there will most likely go unnoticed.

All of this may not matter a hell of a lot if you have so much ram that Windows never uses it all, but it is important to note that many applications reserve much more storage than they actually use.

Even so, I can allocate my entire address space and unless I touch the pages they won't get commited to memory or swap. Unused memory is essentially unallocated.

 

[KoolDrew]

Disabling the pagefile is always a bad idea. Regardless of how much RAM you have.
http://www.windowsitpro.com/Article/ArticleID/42035/42035.html
http://support.microsoft.com/default.aspx?scid=kb;en-us;555223

 

[Markbnj]

It's not an extension of memory, it's impossible for data to be directly accessed inside of the pagefile. It's used as a temporary storage medium for data that doesn't have a backing store anywhere else. So pages that were read from binaries, shared libraries, etc and have no been modified will never be put in the pagefile because they can always be paged back in from the file on disk they originally came from. Pagefile reservations may or may not actually be put in the pagefile, even if they do cause some I/O to put the pages into the pagefile at some point they won't cause any performance changes. The amount of pages in memory that have no backing store is usually pretty small and with disks as fast as they are today writing a few MB/s here and there will most likely go unnoticed.

You do love to wallow in semantics, don't you? Ok, you're right, the pagefile is not an extension of memory, in the same way that the whole virtual memory manager is not an extension of memory, but not in the same way that, say, my keyboard is not an extension of my desk. No, data cannot be read directly from the page file, but then nothing is every _really_ read directly from disk, is it? The pagefile is part of virtual memory, not simply a backing store. The operating system alocates addresses from both physical ram and the pagefile.

Addresses that are reserved by a process can't be reserved by another process. If all the processes that ask for reserved space get addresses allocated from the ram pool, instead of the pagefile, it's probably not good if you don't have a lot of ram in your system.

Even so, I can allocate my entire address space and unless I touch the pages they won't get commited to memory or swap. Unused memory is essentially unallocated.

I venture to say that there is nothing that you as a user, or even a programmer, can do to stop Windows from using the pagefile short of disabling and deleting it.

 

[Nothinman]

You do love to wallow in semantics, don't you?

When dealing with a topic as complicated as VM you have to be precise, mis-wording of crap on Windows and MS' web page is one of the biggest contributers to all of the pagefile tweaking misinformation out there.

Ok, you're right, the pagefile is not an extension of memory, in the same way that the whole virtual memory manager is not an extension of memory,

If you really wante semantics =) Of course the VMM is not an extension of memory, it's a program that manages the memory.

but not in the same way that, say, my keyboard is not an extension of my desk.

Your keyboard has a better chance of being an extension of the desk if you nail it to the edge properly =)

No, data cannot be read directly from the page file, but then nothing is every _really_ read directly from disk, is it?

Sure it could be if you have XIP support, but that's really only useful for things like flash devices that can be mapped directly into memory.

The pagefile is part of virtual memory, not simply a backing store. The operating system alocates addresses from both physical ram and the pagefile.

No, it's not. You can run without a pagefile and still have VM enabled but not vice versa. The OS only allocates addresses from physical memory. It will store pages of memory in the pagefile for safe keeping, but that's it.

I venture to say that there is nothing that you as a user, or even a programmer, can do to stop Windows from using the pagefile short of disabling and deleting it.

Sure there is, you can mlock(2) memory. Depending on your system there might be limits on whether non-priviledged processes can mlock at all or how much a process can mlock, but it's possible to keep memory from being paged out.

 

[Markbnj]

No, it's not. You can run without a pagefile and still have VM enabled but not vice versa.

Of course, since the VMM will not use the pagefile if it isn't there. Which is, I believe, where the discussion started.

Sure there is, you can mlock(2)

I thought we were talking about Windows? Here is a page that explains how it works on the actual operating system we were discussing.

 

[Nothinman]

Of course, since the VMM will not use the pagefile if it isn't there. Which is, I believe, where the discussion started.

Yes, but you said the pagefile is part of VM which isn't any more true than the sound card is part of a game.

I thought we were talking about Windows? Here is a page that explains how it works on the actual operating system we were discussing.

We are, but most aspects of memory management apply to all OSes that do VM even though the specific implementations are different. And it took some time since MS' search engine sucks but I found what looks like their mlock(2) equivalent: http://msdn.microsoft.com/library/en-us/memory/base/virtuallock.asp?frame=true .

 

[gsellis]

For the record, Winodws does use the pagefile, even when memory is abundant. BUT, not for paging. Windows will store key system information that is in memory in the pagefile. That way, if a crash dump does occur, that information is available on the next start.

 

[Markbnj]

And it took some time since MS' search engine sucks but I found what looks like their mlock(2) equivalent:

What that does is lock a region of a particular process's address space into ram. It doesn't affect the overall system-wide use of the pagefile.

I think we really are talking in semantic circles here. Whether you agree that the pagefile is a component of the virtual memory manager isn't very important. The statement you made that prompted my response was when you stated that the pagefile would not be used if there were enough ram in the system to make it unnecessary. In fact it is used in those cases, as my direct experience and all the available info I have seen.

 

[Nothinman]

What that does is lock a region of a particular process's address space into ram. It doesn't affect the overall system-wide use of the pagefile.

I know, you said that there's nothing a user or programmer can do to stop usage of the pagefile. On a global basis, no there's not. But as a developer you can control it for specific parts of your process.

 

[Markbnj]

That we agree on.