Swap File placement

[Irontoes]

I have a 40GB 7200RPM HD with no partitions which is the system drive and a 10GB 5400 HD with no partitions that I use for backup (ghost image), some files, etc... If I moved the swap file off the system drive to the slower 5400 drive do you think I should see any performance gain or loss in Windows XP Pro?

I'm at work right now, otherwise I would just try it

 

[Nothinman]

Windows needs a drive to have atleast 1 partition otherwise it's not mountable.

If you're swapping enough that it matters, you should get more memory. But the general rule is to keep it on the faster drive.

 

[DeeperWell]

The last thing you want to do is put the pagefile on a slower drive. No matter how much physical memory you actually have, Windows XP will always use the pagefile. You want to keep the pagefile on the fastest drive you have. Putting it on a slower drive will degrade performace. Here are some pagefile tips:

1. Keep the pagefile on a seperate drive (or partition). The ultimate would be to have the pagefile on a different drive on a different IDE channel. That may be overkill though. Otherwise, give it its own partition. The reasoning ties into tip #2 below.

2. Override the Windows settings and manually set the minimum and maximum size of the pagefile to the same value. If you let Windows manage the file, it will dynamically expand and contract the pagefile as needed. Don't let it waste time by doing so. Set the value for minimum and maximum size yourself - I usually use the largest of the two numbers Windows comes up with. Another reason for doing this: if Windows is constantly changing the size of the pagefile AND the pagefile does not have its own drive, it will become more and more fragmented. Put the pagefile on its own drive and set the size yourself - you'll have one constant file using a contiguous block of space on your HD.

3. One could argue this is overkill, but the logic is sound, even if the improvements are small. I'm anal about getting every last drop of performance from my system, so I do it. You want the pagefile on the fastest drive you have. I mentioned earlier that the ultimate is a seperate drive on a different IDE channel from your main drive. If it must be on the same drive, put it on the fastest location of your drive - and that is the outer edge. To achieve this, I put my pagefile on the C: drive. My C: drive contains nothing but the pagefile, and I install Windows on D:.

If you follow these guidelines you will pretty much max out the performance on your system with respect to the pagefile.

 

[Nothinman]

1. Keep the pagefile on a seperate drive (or partition). The ultimate would be to have the pagefile on a different drive on a different IDE channel. That may be overkill though. Otherwise, give it its own partition

Putting it on a seperate partition than the OS only makes for extra seeking when it's accessed, it would be better to leave it on the same partition as the OS, specially on a drive with such a slow rotational speed and high seek time.

If you let Windows manage the file, it will dynamically expand and contract the pagefile as needed.

Windows can not contract the pagefile, it only shrinks back to the minimum on a reboot and expansion only occurs when the pagefile is nearly full and if you're swapping that badly I'm sure you'd rather wait a few more seconds while things are swapped out than have things crash because you ran out of swap space.

you'll have one constant file using a contiguous block of space on your HD.

Which is mostly irrelevant because pagefile access is random and in memory page sized chunks (4K on 32-bit systems). Having the file contiguous only helps in the fact that other files won't become fragmented by being written in spaces in the middle of the swap file and even that's a minimal gain.

I'm anal about getting every last drop of performance from my system, so I do it

Then perhaps you should read about how the Windows VM subsystem actually works instead of spreading misinformation like you did in your point #2.

To achieve this, I put my pagefile on the C: drive. My C: drive contains nothing but the pagefile, and I install Windows on D:.

And you probably hurt performance more than help it, because of the extra seeking required for the partition scheme you've used.

In reality there are very few 'optimizations' that can help once you've gotten low on memory and begun swapping to and from disk. Disks are slow, even the fastest RAID arrays are slow as hell compared to everything else in the system. 9 times out of 10 you should just leave the Windows defaults because it's usually smarter than you are.

 

[Irontoes]

Thanks guys, great information.

 

[DeeperWell]

Putting it on a seperate partition than the OS only makes for extra seeking when it's accessed, it would be better to leave it on the same partition as the OS, specially on a drive with such a slow rotational speed and high seek time.

And where did you get that idea? First of all, I stated clearly that he should NOT place the pagefile on the slow drive. But it SHOULD be placed on a seperate partition. Where did you get the idea that putting it on a different partition requires extra seeking? Some more research needs to be done my friend.

http://www.pcguide.com/opt/opt/osSwapLocation-c.html

Windows can not contract the pagefile, it only shrinks back to the minimum on a reboot and expansion only occurs when the pagefile is nearly full and if you're swapping that badly I'm sure you'd rather wait a few more seconds while things are swapped out than have things crash because you ran out of swap space.

Which is why you set the minimum and maximum values to the maximum value Windows suggested when it was running things. You won't run out of swap space in normal situations if you do this.

Then perhaps you should read about how the Windows VM subsystem actually works instead of spreading misinformation like you did in your point #2.

With all due respect, perhaps you should do some more research yourself. I may not know the details of this system, but I know what the common recommendations are:

1. Pagefile should ultimately be on its own drive (the fastest on your system and on a seperate IDE channel from the main drive)
2. If not a seperate drive, its own partition in a fixed size.
3. Placing it on the fastest part of the drive (outer edge, C: partition) will offer fastest read/write times (read up on some HD reviews - there can be big differences in times between inner and outer edges of a drive)

Until you can provide me with credible sources that prove this advice is false I recommend you leave it be. Will these tweaks offer HUGE performance gains? Of course not. When it comes to memory, physical RAM is much faster than VM, as you said, and should be maximized. Having said that, why not give the pagefile the best conditions possible?

Time to do some reading...I think you'll find the consensus is almost unanimous.

 

[Nothinman]

And where did you get that idea? First of all, I stated clearly that he should NOT place the pagefile on the slow drive. But it SHOULD be placed on a seperate partition. Where did you get the idea that putting it on a different partition requires extra seeking? Some more research needs to be done my friend.

If it's on the same physical drive as the OS it might as well be on the same partition, otherwise you do just force extra seeking during pagefile access because the pagefile is farther away from the rest of the files on the drive.

Which is why you set the minimum and maximum values to the maximum value Windows suggested when it was running things. You won't run out of swap space in normal situations if you do this.

You have no idea what 'normal' is for me or the original poster, you can't make generalizations like that. Leaving the upper size of the pagefile open doesn't hurt anything because if you don't ever need the pagefile to grow it never will but if you ever do need it to grow it can but if you've limited it's size you've just caused an allocation to fail and probably an app to crash.

but I know what the common recommendations are:

Just becaue it's commonly recommended doesn't mean it's good, there's a lot of misinformation out there. Anyone can register a domain and put up a web page saying what they think is a good idea.

1. Pagefile should ultimately be on its own drive (the fastest on your system and on a seperate IDE channel from the main drive)

If you're going to spend money on a dedicated pagefile drive save the money and spend it on more memory.

2. If not a seperate drive, its own partition in a fixed size.

Wrong, for the reasons I stated earlier.

3. Placing it on the fastest part of the drive (outer edge, C: partition) will offer fastest read/write times (read up on some HD reviews - there can be big differences in times between inner and outer edges of a drive)

And since pagefile accesses are in 4K chunks at random spots the throughput of those cylinders gets you basically no speed increase. The fact that you're seeking back and forth between partitions will nullify any speed you got from putting it on the outter cylinders and probably actually slow things down more.

Until you can provide me with credible sources that prove this advice is false I recommend you leave it be

Huh? You've not proved anything either, you're in no position to make demands.

When it comes to memory, physical RAM is much faster than VM

I assume you mean pagefile when you say VM, please atleast get the terminology right if you're going to get cocky. Virtual Memory and the pagefile are not even close to being the same thing.

 

[DeeperWell]

If it's on the same physical drive as the OS it might as well be on the same partition, otherwise you do just force extra seeking during pagefile access because the pagefile is farther away from the rest of the files on the drive.

I think this is the most ludicrous thing I have ever heard. So we should never use partitions because all the data is seperated? Until you find me a credible source explaining the 'extra seeking' that goes on when the pagefile is on a different partition, my original recommendation stands. There is no 'extra seeking'. Performance will be better because more than likely the drive's performance is better at the outer edge. I suggest you do some reading:

http://www.storagereview.com/welcome.pl/http://www.storagereview.com/articles/200201/20020124WD1200JB_2.html

You have no idea what 'normal' is for me or the original poster, you can't make generalizations like that. Leaving the upper size of the pagefile open doesn't hurt anything because if you don't ever need the pagefile to grow it never will but if you ever do need it to grow it can but if you've limited it's size you've just caused an allocation to fail and probably an app to crash.

No I don't. But in most cases of 'normal' computer use, Windows' recommendation in terms of maximum file size can be heeded without issue. If the computer is being used for extremely memory-intensive purposes, then the user probably already has a significant amount of RAM and is well-aware of the importance of pagefile performance. Or perhaps he is just learning. Oh, and please explain how you leave the upper size of the pagefile 'open'? Windows requires a value in the Maximum entry box as well as the minimum - whether you do it or let Windows do it. So explain how this can be left open??

Just becaue it's commonly recommended doesn't mean it's good, there's a lot of misinformation out there. Anyone can register a domain and put up a web page saying what they think is a good idea.

Clearly you ignored me and did no research, but rather just continued your rant. Look around. These recommendations are practically unanimous. They are not simply posted on a bunch of one-off domain names. Where is the information to back up your claims?

If you're going to spend money on a dedicated pagefile drive save the money and spend it on more memory.

I already stated that

a) a seperate drive is overkill. A logical person would dictate that that means don't buy a seperate drive for the purpose, but if you have one and it is not being used, use it.

b) more physical memory is preferable to pagefile use, no matter how optimized.

Wrong, for the reasons I stated earlier.

With all due respect (and the amount of this as you continue this is dwindling), you are wrong. You have provided no solid foundation for this claim.

I assume you mean pagefile when you say VM, please atleast get the terminology right if you're going to get cocky. Virtual Memory and the pagefile are not even close to being the same thing.

LOL...alright Notinman, all respect for you is now lost.

System Properties -> Advanced -> Performance Settings -> Advanced -> Advanced Tab

'Virtual Memory: A paging file is an area on the hard disk that Windows uses as if it were RAM.'

Virtual Memory and Pagefile are the same thing. Give me a break.

Huh? You've not proved anything either, you're in no position to make demands.

I believe you will find a link making the same recommendations as myself. Further, you will find my recommendation to do a search and read a bit - as you peruse other websites (not all fly-by-nights as you like to think) and message boards, you will find these recommendations more or less unanimous. There are always questions regarding how effective they are and I have acknowledged these. No, this kind of optimization will not improve system performance by 80%. You will also find another link providing background for the theory of placing the pagefile on the outer edge of the drive.

You, on the other hand, have provided nothing. Except this claim about 'more seeks' on a different partition.

Nothinman, I have no idea what your problem is. But you need to do some serious research. Contrary to what you might think, you do not know everything. And, to prevent a rebuttal to this: I am NOT claiming I know everything myself. The two statements are not mutually exclusive.

In case anybody else is reading this thread, let us some up. Best pagefile advice:

1. Put it on a seperate drive (on a different IDE channel from the main drive) or on a seperate partition.

2. Make that partition on the outer edge of your drive, as more than likely it has the best transfer rates.

3. Override Windows settings and set the minimum and maximum values to the same value. A good rule of thumb is to set this to whatever Windows felt was a good maximum when it was running things.

Incidentally, perhaps you already have the pagefile on the same drive as your Windows installation (the default of a Windows setup). When you defrag, the defragger (at least the Windows defragger, I have not tested others) cannot touch the pagefile. Also, the pagefile will more than likely be highly fragmented, sort of 'filling in the holes' of a fragmented drive. When you defrag it will be difficult with this file in the way. So, before you defrag, move the pagefile to another drive or partition and then defrag. Put the pagefile back after the defrag - you will have a more contiguous pagefile and your files will be better organized as well.

 

[Nothinman]

I think this is the most ludicrous thing I have ever heard. So we should never use partitions because all the data is seperated?

No, but if you want to make pagefile access as fast as possible it makes sense to avoid the most time consuming part of hard disk access, which is seeking.

Until you find me a credible source explaining the 'extra seeking' that goes on when the pagefile is on a different partition, my original recommendation stands

Do you have any idea how a hard drive works? That noise coming from your hard drive during read/write activity is the motors causing the heads to seek, that's where the drive spends most of it's time.

That link you posted is pointless. Almost all hard disk access is random, the only time you do large amounts of sequential reading or writing is really during a benchmark or when copying large files from one drive to another. 99% of disk access is random and in small chunks, the pagefile even more so because the chunks are only 4K because that's the pagesize on a 32-bit system.

If the computer is being used for extremely memory-intensive purposes, then the user probably already has a significant amount of RAM and is well-aware of the importance of pagefile performance. Or perhaps he is just learning.

Not really, I've seen many CAD users that have no idea what a pagefile is and they shouldn't have to. You can't make assumptions like that.

'Virtual Memory: A paging file is an area on the hard disk that Windows uses as if it were RAM.'

I realize that's what the dialog says, but MS' GUI designers don't know the terminology either. If you read some documents in the MSDN, where the actual technical people write the docs, they use the terminology properly.

It is you who needs to do some research.

From your own link:
To really put seek time in proper context, it should be remembered that it is the largest component of access time, which is the composite metric that best represents positioning performance.
And
This difference of 5 ms represents an enormous performance difference between these two drives, one that would be readily apparent to any serious user of the two drives.

2. Make that partition on the outer edge of your drive, as more than likely it has the best transfer rates.

No matter how many times you type it, it's still wrong.

 

[DeeperWell]

Nothinman...what the hell is your problem??

No, but if you want to make pagefile access as fast as possible it makes sense to avoid the most time consuming part of hard disk access, which is seeking.

You STILL have not explained the extra seeking that occurs if the pagefile on a seperate drive as opposed to the Windows drive. Please explain why there are extra seeks. I am dying to know.

That link you posted is pointless.

Yes, I know how a hard drive works. The link I provided was intended to highlight differences in transfer rates: 49.9MB/S in the outer-zone areas vs. 29.2 in the inner. Of course this will vary from drive to drive. Point is, transfer rates are better in the outer zone.

realize that's what the dialog says, but MS' GUI designers don't know the terminology either. If you read some documents in the MSDN, where the actual technical people write the docs, they use the terminology properly.

OK, where is the proof? I want solid evidence that the pagefile has completely, totally, absolutely NOTHING to do with virtual memory. I am so excited for this enlightenment. In every forum of discussion I have come across, people use the term pagefile when referring to virtual memory. Even the days of swap files in old Windows 3.1 was considered virtual memory.

No matter how many times you type it, it's still wrong.

Newsflash: YOU are wrong.

Did you read the link I provided you?? Measured fact: transfer rates are better in the outer-zone than the inner. 49.9MB/S vs 29.2.

I will not sit idly by while you accuse me of spreading misinformation. So far you have provided no solid evidence to further your claims. Unless you consider solid evidence repeatedly typing 'You're wrong'.

 

[DeeperWell]

Also, a quote from Microsoft Knowledge Base Article 307886:

The paging file is the area on the hard disk that Windows uses as if it were random access memory (RAM) This is sometimes known as "virtual memory."

Also, a quote from Microsoft Knowledge Base Article 314482:

The paging file (Pagefile.sys) is a hidden file on your computer's hard disk that Windows XP uses as if it were random access memory (RAM). The paging file and physical memory comprise virtual memory.

A further quote from Article 314482:

To enhance performance, move the paging file to a different partition. When the paging file is on the boot partition, Windows must perform disk reading and writing requests on both the system folder and the paging file. When the paging file is moved to a different partition, there is less competition between reading and writing requests.

Yet another quote from 314482:

When you place a paging file on its own partition, the paging file does not become fragmented, and this counts as another definite advantage. If a paging file resides on a partition that contains other data, it may experience fragmentation as it expands to satisfy the extra virtual memory that is required.

That reading from the Microsoft Knowledge Base definitely proves your claims are baseless. Unless of course you will claim that the writers of the Knowledge Base don't know anything either.

 

[Nothinman]

Nothinman...what the hell is your problem??

People who don't understand VM and paging spreading misinformation.

You STILL have not explained the extra seeking that occurs if the pagefile on a seperate drive as opposed to the Windows drive. Please explain why there are extra seeks. I am dying to know.

Because the data is sperated on the platters, do you have any idea how partitions are sperated on a disk?

If you have a pagefile partition at cylinders 0-10 and an OS partition on cylinders 11-50 and you're reading data from cylinder 35 for instance to start a program but now you have to swap out because memory is low, now you have to seek back to cylinder 0 write a page or two then seek back to cylinder 35 and page in more of the executable. Repeat more depending on how low memory is. Considering each seek takes ~9ms on a common IDE drive, that adds up quickly.

Yes, I know how a hard drive works. The link I provided was intended to highlight differences in transfer rates: 49.9MB/S in the outer-zone areas vs. 29.2 in the inner. Of course this will vary from drive to drive. Point is, transfer rates are better in the outer zone.

But it's irrelevant. Pagefile access is not sequential, you only read a page or two at a time. So the fact that you can read 4K at 50MB/s is pointless.

OK, where is the proof? I want solid evidence that the pagefile has completely, totally, absolutely NOTHING to do with virtual memory

The pagefile is related to VM because without VM and the hardware support provided by the processors MMU there would be no way to tell what pages are in memory and which ones aren't, but it's not the same thing.

http://cne.gmu.edu/modules/vm/green/defn.html : The term virtual memory refers to the abstraction of separating LOGICAL memory--memory as seen by the process--from PHYSICAL memory--memory as seen by the processor

This abstraction allows the OS to move pages to disk to allow physical memory to be used for other things but the pagefile itself is not required for VM.

I am so excited for this enlightenment. In every forum of discussion I have come across, people use the term pagefile when referring to virtual memory

That's because MS has people trained to think that, but it's not even close to being correct.

The paging file is the area on the hard disk that Windows uses as if it were random access memory (RAM) This is sometimes known as "virtual memory."

Well if you read a book like "Inside Windows 2000" or "Understanding the Linux kernel" and see how swap space you'll see how inccorect both of those statements really are.

Windows must perform disk reading and writing requests on both the system folder and the paging file. When the paging file is moved to a different partition, there is less competition between reading and writing requests.

The competition still exists because it's on the same drive, IDE drives can only process 1 command a time so unless you put the pagefile on another drive and channel completely it's pointless.

That reading from the Microsoft Knowledge Base definitely proves your claims are baseless. Unless of course you will claim that the writers of the Knowledge Base don't know anything either.

That would seem to be true. My company has a lot of documentation writers that don't understand the software or methods they're writing about, I would assume MS has the same type of writers. Microsoft's documentation is far from infallable.

 

[DeeperWell]

Wow Nothinman, you don't stop do you??

Because the data is sperated on the platters, do you have any idea how partitions are sperated on a disk?

Yes, I understand it quite well thank-you. You STILL have not explained where these EXTRA seeks come in? The only difference is that the seeks will be in different locations. But in less in your little world EVERYTHING is located at cylinder 35, the number of seeks will be the same - just in different locations. Where are these EXTRA seeks coming from??

This abstraction allows the OS to move pages to disk to allow physical memory to be used for other things but the pagefile itself is not required for VM.

Ummm...hello?? That is exactly what the pagefile is doing. The total of physical memory and pagefile size is what is seen as LOGICAL memory by the process. You STILL have not explained how the pagefile and virtual memory are completely and totally seperate??

That would seem to be true. My company has a lot of documentation writers that don't understand the software or methods they're writing about, I would assume MS has the same type of writers.

I would say it is unfortunate your company has YOU. Very unfortunate.

 

[Nothinman]

The only difference is that the seeks will be in different locations. But in less in your little world EVERYTHING is located at cylinder 35, the number of seeks will be the same - just in different locations. Where are these EXTRA seeks coming from??

Sorry, the number of seeks will probably be the same, but there's way too many other variables involved to really know how many seeks there will be. But either way the time required to seek to the outter cylinder is longer than seeking only a few cylinders and the fact that you're seeking to only read in a few pages at the most, the 9ms you wasted seeking all that way negates the speed benefit those cylinders provide.

Ummm...hello?? That is exactly what the pagefile is doing.

And you totally ignore the other quote.

No matter how much physical memory you have you always have 4G logical memory available to each process on a 32-bit system. Each process has their own address space seperate from all the others, this is the reason that no process can read another process's memory without the use of another mechanism such as shared memory, a pipe or a file. The CPU has a set of tables that map virtual addresses (what the process sees) to physical addresses in memory so that when the process asks for a certain page of memory it can retrieve it from memory or cause a page fault and let the OS find it, put it somewhere new in memory then map that new physical page to the virtual page the process expected then continue the process like nothing happened.

The swap space is only used as a repository to dump pages when physical memory needs freed, without VM the OS would have no mechanism to move pages around transparently like it does to keep the system running well. But without the pagefile VM is still enabled and being used, just without the ability to free some of that memory when it needs to (some of it can be freed from things like executables and shared libraries because they can always be paged back in from their original location on disk).

Do I need to go into more detail?

I would say it is unfortunate your company has YOU. Very unfortunate.

You have no idea how misinformed you are on internal OS operations.

If you're still not convinced read this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcedesgn/htm/_wcesdk_Using_Virtual_Memory.asp and tell me how WinCE supports Virtual Memory but not a pagefile when they're the same thing according to you.

 

[drag]

I am actually realy curious of what the correct definition of "virtual memory" is vs a page file. My limited educational guess is that page file refers to the actual physical space on the harddrive that is used for writing exess RAM crap to when you run out of room. Virtual memory is more of a abstract term that refers to what a program witnesses when it is trying to write to RAM. You have 256 megs of RAM and maximum of a 1 gig page file sitting there on the harddrive. So you conceptually have up to 1.25 gigs amount of virtual memory. To say that virtual memory is faster then a page file or a page file is another term for virtual memory is completely BS. They are on different layers of abstraction. It's like comparing apples to oranges.

Plus the argument of saying that if you put the page file on the outer edges it increases readwrite time is equally pointless. Thru studying OS's I've learn that the best performance comes from putting the OS towards the center of the drive. Even though you are sacrifcing read write potental the amount of time it takes for the head to read the information is much less important then the time it takes the head to actually TRAVEL to the spot it needs to get the information. Most of the time the harddrive head is traveling across the platters in order to get to the information not actually reading or writing the information. Towards the center or the platters their is just that much less space for the head to travel to get from one sector to another.

Now if the page file was one continuous thing then it would make sense to stick it on the edge, but then again it would make more sense to install a tape drive and read it off of that, because modern tape drives have potentially much more faster read/write times once they get going, but since the page file is randomly accessed you see how silly it is.

Now as far as having the page file on it's own partition. This is not to increase performance, it is for housekeeping. You don't want the page file to be invading the file space on your OS partition if you filled up that partition and fragmenting the hell out the new service packs you have to install. Now that would kill performance.

Putting it on a different hd, now I believe that CAN increase performance. Just as long as it is on a seperate IDE controller. That way it can be reading for one harddrive and writing to the other at the same time. If they are on the same controller then you lose most of that benifit. And having one HD terribly slower then the other may just cancel out that benifit altogether compared to putting it on the faster HD.

 

[Nothinman]

drag, you mostly have it in the first paragraph except that the size of virtual memory is constant. You always have 4G (2G is reserved for the OS) of VM on a 32-bit system no matter how much physical memory and pagefile space you have available. The best part is you can have 8G of physical memory but a single process can only access 2G of that (3G with a little configuration), this is why 64-bit OSes are popular for things like databases that need gobs of memory.

 

[drag]

yessir!

 

[ProviaFan]

Originally posted by: Nothinman

The only difference is that the seeks will be in different locations. But in less in your little world EVERYTHING is located at cylinder 35, the number of seeks will be the same - just in different locations. Where are these EXTRA seeks coming from??

Sorry, the number of seeks will probably be the same, but there's way too many other variables involved to really know how many seeks there will be. But either way the time required to seek to the outter cylinder is longer than seeking only a few cylinders and the fact that you're seeking to only read in a few pages at the most, the 9ms you wasted seeking all that way negates the speed benefit those cylinders provide.

The way I see it, it's like walking to across a room to get something and then coming back 10 times, or walking to another room on the other side of the house (at the same speed) and coming back 10 times. It should be obvious to everyone except certain trolls that have preconceived notions and don't want to admit that they're wrong that the latter will take longer than the former.

Ummm...hello?? That is exactly what the pagefile is doing.

And you totally ignore the other quote.

No matter how much physical memory you have you always have 4G logical memory available to each process on a 32-bit system. Each process has their own address space seperate from all the others, this is the reason that no process can read another process's memory without the use of another mechanism such as shared memory, a pipe or a file. The CPU has a set of tables that map virtual addresses (what the process sees) to physical addresses in memory so that when the process asks for a certain page of memory it can retrieve it from memory or cause a page fault and let the OS find it, put it somewhere new in memory then map that new physical page to the virtual page the process expected then continue the process like nothing happened.

The swap space is only used as a repository to dump pages when physical memory needs freed, without VM the OS would have no mechanism to move pages around transparently like it does to keep the system running well. But without the pagefile VM is still enabled and being used, just without the ability to free some of that memory when it needs to (some of it can be freed from things like executables and shared libraries because they can always be paged back in from their original location on disk).

Do I need to go into more detail?

I would say it is unfortunate your company has YOU. Very unfortunate.

You have no idea how misinformed you are on internal OS operations.

If you're still not convinced read this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcedesgn/htm/_wcesdk_Using_Virtual_Memory.asp and tell me how WinCE supports Virtual Memory but not a pagefile when they're the same thing according to you.

It's lovely how one of his own quotes from a MSKB article disproves his "pagefile == virtualmemory" thing (even then the quote isn't exactly accurate, but it's close):

The paging file (Pagefile.sys) is a hidden file on your computer's hard disk that Windows XP uses as if it were random access memory (RAM). The paging file and physical memory comprise virtual memory.

Now, I'd like him to explain that last sentence to me; if both the page file and physical memory comprise the virtual memory, then how can the page file alone equal the virtual memory. It's very hard to find any contradiction there...

 

[Nothinman]

It seems obvious that the MSDN writers are more concerned with the correctness and quality of the documents than those who do the KB articles, and that's not a terrilbe thing because most of the time the people readin the KB articles don't care about the specific details but just want to know how to fix their current problem.

But the problems arise when you just go to MS KB and declare whatever they say as gospel, you need to take input from multiple sources. There are many documents describing VM and it's application to current OS design.

 

[drag]

Oh well. live and learn. We've all been plenty wrong in the past here before anyways. Yep todays leason was: amount of virtual memory aviable= page file + ram < or = to 4 gig. And 4 gig is what the virtual memory size realy is, and that is dictated by the limit of of 32 bits architecture.

So to increase virtual memory performance you need to make sure that you can get as much RAM as possible to populate it, because paging is just so damn slow.

In windows is there any real way to increase pagefile performance? Any reg hacks or whatnot? I know in linux that you can actually use a page file ala windows, but only at a performance penatly when compared to a dedicated swap partition with it's own special format designed specificaly for paging.

Is there any swap partitioning possible with any version of windows? Maybe 2003?

 

[Nothinman]

I know in linux that you can actually use a page file ala windows, but only at a performance penatly when compared to a dedicated swap partition with it's own special format designed specificaly for paging.

Another clarification =)

The reason a swap file is slower than a swap partition is because to read/write to the file all the access have to filter through the VFS and filesystem, but access to the swap partition just goes straight to the device. There's no real format to the swap partition or file, all mkswap does is write a small signature to the end of the partition/file so that you can't accidentally swapon the wrong device.

Is there any swap partitioning possible with any version of windows? Maybe 2003?

Actually I vaguely remember seeing a driver that will allow you to use Linux swap partitions for swapping in Windows, I never tried it though.

 

[DeeperWell]

Alright, I will openly apologize for my choice of words, in an effort to discount myself as a 'troll' (which I am not, just a new member).

I did originally make the statement that the pagefile and VM were the same thing. It is wrong and not what I meant. What I meant to say was that they are related. I was trying to find out why Nothinman was trying to imply that they had nothing to with each other. So yes, you are correct: they are not the same thing. But related.

Keep one thing in mind: we are not in the highly technical forum here. For most people, using the terms interchangeably will have no ill effect. We do not all have to understand the intricacies of OS design to grasp concepts.

I still have not seen, however, solid proof that my recommendations deserve to be called 'misinformation'. They are harmless recommendations. As I had stated many times before, their effectiveness has been debated. And I do not delude myself that these things make my system run 80% faster. But they may help performance somewhat - and even if it is a small amount, I will take it.

 

[Nothinman]

If it makes any difference I never thought you were a troll, just misinformed =)

I was trying to find out why Nothinman was trying to imply that they had nothing to with each other. So yes, you are correct: they are not the same thing. But related.

They are related, but VM does not require a pagefile but the use of a pagefile requires VM. The real problem is MS' misuse of the terms, everywhere but their development sites seems to have no idea how the terms should really be used.

I still have not seen, however, solid proof that my recommendations deserve to be called 'misinformation'.

Sorry, misinformation is probably harsh. But irrelvant or pointless is accurate IME.

And I do not delude myself that these things make my system run 80% faster. But they may help performance somewhat - and even if it is a small amount, I will take it.

And I still stand by my opinion that the extra seek time (not extra seeks =) ) required to move between partitions negates any speed increase gained by putting the pagefile on the outter cylinders. One of the reasons SCSI drives still kick IDE ass is because they have such low seek times, IDE drives just feel sluggish even with 8M cache after you run on a 15K RPM Cheetah for a while.

 

[ProviaFan]

Originally posted by: Nothinman
And I still stand by my opinion that the extra seek time (not extra seeks =) ) required to move between partitions negates any speed increase gained by putting the pagefile on the outter cylinders. One of the reasons SCSI drives still kick IDE ass is because they have such low seek times, IDE drives just feel sluggish even with 8M cache after you run on a 15K RPM Cheetah for a while.

And I thought that my new 80GB "SE" Western Digital was a big improvement over my 20GB Western Digital (both 7,200RPM). Now I feel the need to upgrade to a SCSI disk for my OS and programs. Must... resist... temptation...

 

[DeeperWell]

Sorry, misinformation is probably harsh. But irrelvant or pointless is accurate IME.

Alright, I can accept that.

It boils down to differences of opinion which I stated you will find if you do a search on this subject. Some feel it is worthwhile, others not. Whatever the actual performance benefits may be, there is certainly no harm in doing so.

Also, to go full circle right back to the beginning question - can we all agree that he should NOT place the pagefile on the slower 5400RPM drive?

To gain any real benefits, as I had mentioned earlier, you would need a faster drive placed on a seperate IDE channel. But even I am not that anal.