The pagefile is not configurable to anywhere other then where the OS places it, as I know it.

Even still, this isn't an area that needs tweaking, as I know it.

Admittedly very few apps use the pagefile.
Although I did find 1.7GB of data in there just then, but I think I had an app that had developed a memory leak.

Rodrigo wrote: so, where should i put the Pagefile?
and... for what purpose should I use the IDE vs. SATAs?

Pagefile placement is one of those arguable items that may be right for one setup and not the next.

You can move it to anywhere you want... but depending on drive characteristic, I/O chipset and drive format, you can actually hurt performance as opposed to increasing it.

If you have more than two channels of disk I/O, then you can handle more than 4 drives... and arguably, you have enough I/O bandwidth to handle the pagefile processing.

If you have slower drives or slower I/O, then the I/O transfers could be a bottleneck to the OS and the pagefile... and likely putting the pagefile on its own (SMALL capacity drive) could yield a significant performance increase.

With SATA drives, you would think that the issue of pagefile access would be moot, but it continues to be one of those "gotta tweak it to find out" things.

However... putting a pagefile on a large drive (250Gb or larger) is not only a waste of space, but that space can become a performance liability. The pagefile consists of a lot of markers and pointers... As such, those items being on another drive, they get pointers to other pointers... including the index. If it's a large drive, it's gonna be a large, albeit empty, index. Constantly running through a large index takes time. If it takes a lot of time, you end up missing out on I/O rountines... and thus... performance suffers... big time.

Unfortunately, there's no hard and fast rule here.... about all I can tell ya is to try it.

Page file placement is only going to be an issue if the OS is going to have to do paging. Paging happens when the OS doesn't have enough RAM to keep all of it's process and thread in main memory at once. Where you put the page file depends on how much you are accessing your various drives under typical workload. You would want to put the PF on drive(s) that have relatively little activity, and that have fast access. Also keep in mind that you can put the page file on multiple drives (kind of like RAID).

If paging is an even an issue, the fastest solution would probably be a small solid state drive (for big bucks). A more affordable solution would be the smallest WD Raptor you can get.

I still haven't found how a user can alter where a pagefile will be printed, in win xp at least.

You can select a few things like specific size or no page file per individual drive, but my box does not show a setting that allows anything beyond this simple tweak.

If you're comfortable in regedit try this

http://tinyurl.com/coo3d2

i've been using a mac for some time now. That's a good option.....
:D

mudpuppy wrote: Paging happens when the OS doesn't have enough RAM to keep all of it's process and thread in main memory at once.

OK, so that means that any installation of any version of Windoze WILL need a page file. 8-)

MadMax wrote:
OK, so that means that any installation of any version of Windoze WILL need a page file. 8-)

Pretty much. You can check paging activity w/ windows task manager. I'm always surprised that my machine needs to page with WinXP and 2G of ram.

Windows also likes to have a page file big enough to to dump all of its RAM to when you get the BSOD (blue screen of death).

One optimization tip is to make sure that the page file is plenty big, at least 2x your ram. You don't want to have windows do dynamic resizing of the file.

mudpuppy wrote: [quote=MadMax]
OK, so that means that any installation of any version of Windoze WILL need a page file. 8-)

Pretty much. You can check paging activity w/ windows task manager. I'm always surprised that my machine needs to page with WinXP and 2G of ram.

Windows also likes to have a page file big enough to to dump all of its RAM to when you get the BSOD (blue screen of death).

One optimization tip is to make sure that the page file is plenty big, at least 2x your ram. You don't want to have windows do dynamic resizing of the file.

uhhhh... only up to 2Gb of RAM. After that, Windoze will start to crush itself under the weight of attempting to manage the drive space reserved for the page file.

I can't say for sure about Vista, 7 or 8 yet, but from XP back to 3.11, the Redmond Retards have this aversion to writing clean I/O code. The whole I/O routine seems to be about read/write states being held for the slowest of all possible RAM, and letting the buffers just choke on address range processing.

By the very nature of processing for least common denominator, the actual setting of the page/swap file is a bit of a tedium that few folks will actually take the time and patience to deal with.

I've seen the performance be lightning fast, or dog assed slow with the same settings of two very similar boxes... e.g. same drives, same amount of RAM and same basic config... different mobo's/RAM types.

Oh yeah... and the funniest thing is when you have in excess of 2Gb of RAM... Windoze "says" it has turned off paging... it really hasn't, it's just that the OS is set to manage it for you, since the code hacks in Redmond assume you aren't smart enough to drop the page file to the minimum of 512Mb.

So, the bottom line is that to get peak performance for I/O throughput, you do have to tweak it for individual boxes...