As I understand it, the HDD remains a bit less fragmented, resulting in a general system performance increase, if the Paging File is put on it's own partition. Furthermore, it seems generally accepted that if the Paging File partition can be put close to the center of the disk, it will perform faster than if placed on the outside of the disk.

I'm running 2GB RAM, and XP "suggests" 3.07GB for a Paging File.
I have a new 80 GB hard drive, so if XP really needs 3GB for a Paging File, I have no problem with that.

-But does it?
What size do you all recommend?
Is there truth in in the relationship of performance and partition location for it?
How do I lay out the partitions? Do I create a "B" partition, or a "D" partition? -In other words, in partitions B, C, D, (say "E" is the ROM), which one is closest to the center of the hard drive?

I could set it up so it's called "B" initially, and then when the disk is all formatted and ready to lay down the OS, I could rename it "D" (or whatever), and the physical partition will still be where it was originally put, correct?

On a sidenote; if we no longer use floppies, why do we still never use the letters "A" & "B" as names for partitions or removable memory?

How much paging space you need really depends on what you do with your system.

For most operations you're safe to turn off paging altogether with 2GB.

If you do heavy (and I mean really really HEAVY) photoshop work, then it's possible you'd need paging space.

If I were in your position, I'd leave maybe 1GB just to be safe. No more than that.

I can't see that a separate partition will help speed things up as it will still be on the same physical disk. Putting your page file on a different physical drive to your system files, and splitting the page file between multiple hard drives are methods recommended by microsoft to improve performance. However, few laptops have the luxury of multiple drives.

see: <http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/computer_maint_perf_mgmt.mspx>

Well, now I'm confused a little.
It seems that the Paging File "virtual memory" situation just needs a minimum of 2MB for it's file/.exe. That makes sense.
It also makes sense that the Pging File would only need to be employed when the RAM is maxed out.
I have seen where RAM allocations are set for specific tasks in the guts of XP (can't recall offhand), but the amounts don't come close to taxing my 2GB of RAM! When I bought it, I knew it should be way, way more than enough for any application/program I have.

So my confusion is regarding the fact that my Paging File seems to be working. Why is ANY of it being employed? (I forget the particular system viewer that I saw this in, but I can relocate it.)

The other part of my confusion is regarding the size that Microsoft suggests for the PF. 150% of your RAM...Why would you need more PF with more RAM? It would be a very simple program to have in XP to decrease the "recommended" PF size as RAM is increased, especially given the few sizes possible with the available increments in RAM.
So why isn't the system suggestion for Paging File size directly inversely proportional to the amount of RAM installed?


As far as the seperate drive vs seperate partition, that makes much more sense.
In Paging File allocation, you can set what disk/partition you want it on.
I have a PCMCIA car with a 512 CF card in it. What will I need to format that card to in order to use it as a paging file? Will solid state work?

Heh-heh...Can I then brag about having 2.5 GB of RAM? j/k

Nope, that's not the way it works. Windows does not wait until the memory is saturated before it starts paging things to disk. The condensed version is: Windows juggles things so that memory pages that have been recently accessed are in physical memory, while those that haven't been accessed in a while are paged to the disk. Things that get paged to disk are copied to the pagefile and those memory pages are placed on the standby list. Here's the important part: pages on the standby list are the last pages that get cleared and released for use by other applications. That way, if the program all of a sudden needs pages that are on standby, they are already in memory and Windows just needs to change their status. In fact, applications don't see physical memory and space on the disk used for paging; programs ask Windows for memory and it gives it to them. The OS is then responsible for putting the pages that are needed currently into the physical memory, while those that aren't needed immediately can be sent to the disk. Also, disabling the paging file doesn't mean Windows will stop paging things to disk. It just doesn't page them to pagefile.sys (and very few people realize that).

Less pagefile space with more memory is definitely not what you want. Think about it this way, what if you launched some program that wanted to use just about all your 2 GB of physical memory (a modeling program, deconvolution software, whatever)? If your paging file is bigger than your physical memory, Windows could send all pageable memory to the pagefile and give that memory-hungry application all the room it needs to work. In other words, the pagefile backs your physical memory. It's there to make sure Windows has room to work for your applications. If you have less pagefile space than physical memory, and all of a sudden Windows needs to free a lot of RAM, it has to make choices about what gets to remain backed by the pagefile and what has to get completely tossed from the virtual memory system.[/quote]

That drive will have lower latency than a hard drive, but I doubt the throughput will be better than a modern hard drive. That drive also won't be available during boot until the driver loads, and Windows makes liberal use of the pagefile during startup if one is available. And as was said above, putting the pagefile on a separate partition on the same drive as the OS is bad for paging performance. If you do that, the disk will require an extra stroke just about everytime the OS needs to access the pagefile. Don't worry about fragmentation; it is a non-issue for the vast majority of all computers. Even if Windows expands the pagefile onto a couple fragments, the extra extents will be erased at next boot (which will happen about once a month if you have automatic updates on).

Some people are going to tell you that you can run without a pagefile with that much memory. In a myopic sense, they're right. Under normal use, you probably won't have any issues. But the goal of the pagefile is to minimize hard page faults to reduce the amount of time your system spends in the filesystem driver. If you ever see a situation where you do eat up all that memory (an out-of-control driver, a heavy Photoshop session or something like that) and you don't have a pagefile, your system will flip-out on you. In the meantime, the presence of a reasonable pagefile isn't going to negatively impact performance.

My advice, set it to a system managed size and forget about it. Windows will do its job and you can use your computer, rather than waste your time overthinking how to optimize what the OS is designed to do from the ground up anyway.

Ohhhhh Thank you -Thank you!

So in effect, Page Filing is like "behind the scenes" indexing?

There was some test numbers up on Blackviper before testing different page setups, primary, secondary, static, dynamic, and i believe also partitioned. The site is down for now but maybe you can check it out in the future if they ever make it back up.

He should pick a size and set both the minimum and maximum to that size because when you have a different min and max the page file becomes fragmented very quickly from being resized all the time. Other then that though he should just leave the page file alone. It does no good to put the page file on another partition on the same physical drive. The hard drive will have to try and access the windows partition and the page file partition at the same time and thats not going to happen.

But the pagefile doesn't get resized all the time. As a result it doesn't fragment very quickly, if ever. It get resized on occasion. When set to a system managed size, Windows starts with a pagefile 1.5 times the size of the physical memory. The pagefile will not change in size unless the commit limit is reached. It doesn't care if you don't need that much space; it won't shrink it below that.

So the key question is: if he never pushes his commit limit, how is this any different than those who suggest setting the min and max size to 1.5x the amount of RAM in the computer? It's not if his commit charge doesn't exceed the size of the RAM+pagefile. Where the two setups differ are the cases where he does hit the limit. In those cases, the system with the pagefile that can't be expanded can't add more pages. In the system with a dynamically sized pagefile, an extra extent is added. Even if the pagefile cannot be expanded contiguously, it's only one more fragment. Performance-wise, that a nonissue.

1. there is no ratio or percentage for page file recommendation
2. page file performance is the best when it's on the same partiotion with ur os- unless the partiotion where the os is located is heavily fragmented, and then ANY location for the page file is better...
3. i have 1gb of ram. i dont use my pc for 3d rendering\Fs. never had more than 700mb page file. (min=700 max=700)
4. the best way to find ur page file size is just to load ur computer as heavily as it might be loaded, and check task manager for peak memory usage (alt+ctrl+del under "performance") set it accordingly and leave some 100mb extra