PDA

View Full Version : How does Page Filing work?


darksparkz
12-05-05, 04:47 PM
I understand that when you start using all of your ram, Windows switches to relieve some stress onto the slower HDDs, is that what page filing is? I recently upgraded to 2GB of ram from 1GB and is wondering is there anything I should set for page filing. In Task Manager, while only a few applications are running, it says "PF Usage" is at 263MB, is there anywhere I should set to change that or anything?

What's the recommended settings for 1GB or 2GB of ram? Or should I just leave it as it is and let Windows take care of it.

klingens
12-05-05, 05:15 PM
No you can't change anything. Windows will do everything automatically.

Basically what happens is this:all the programs you run will use up more RAM than you actually have. So part of the RAM content which currently isn't needed is swapped out to the harddisk. When it's needed again for some reason it's read into ram again and some other memorypages are swapped out instead,etc.
WindowsXP always uses swap even when the loaded programs don't fill your memory since it uses a lot of your RAM for caching

pwnt by pat
12-05-05, 05:19 PM
With two gigs you can disable page filing completely.

right click my computer -> properties
advanced tab -> performance "settings"
advanced tab -> virtual memory "change"

"no page file" -> set
restart

K15
12-05-05, 09:00 PM
With two gigs you can disable page filing completely.

right click my computer -> properties
advanced tab -> performance "settings"
advanced tab -> virtual memory "change"

"no page file" -> set
restart



I would do that too, then observe task manager for RAM usage.

Enablingwolf
12-05-05, 09:03 PM
I disabled page file once.

I got crazy gripe dialogs in Photoshop and some other apps. Some games did not like me either. So if you do disable the pagefile, make sure it suites your needs.

pwnt by pat
12-05-05, 09:43 PM
I've been disabling it since I got one gig of ram.... since I put my computer first together (a couple years ago). I've had no problems. YMMV

BrutalDrew
12-05-05, 10:21 PM
You should never disable the pagefile. All you are doing is hurting yourself in the long run by causing more paging of code for a given workload and RAM size.

As for the optimal PF size just run your most intensive applications for a while and observerve your PF usage through perfmon (the graph in task manager labeled "PF Usage" is not PF usage, oddly enough). Set the pagefile like this:

Let x = Observed PF usage

Initial = 4x
Max = 2(4x)

Letting Windows take care of it is actually a good idea too.

pwnt by pat
12-06-05, 01:15 AM
That goes against everything I've ever heard or read, leaving windows manage a pagefile. Something to do with windows will resize the allocated amount ending up in overall slower performance due to the necessary expansion/contraction of the page file...

Captain Newbie
12-06-05, 10:11 AM
That goes against everything I've ever heard or read, leaving windows manage a pagefile. Something to do with windows will resize the allocated amount ending up in overall slower performance due to the necessary expansion/contraction of the page file...
And resulting in fragmentation, making the paging process slower.

Although the page file should not be disabled. As clunky as Win32 VM is, it's what you have.

As for managing the pagefile, it's perfectly permissible to let Windows do it anyway, since it'll eventually get fragmented and bloated anyway.

aftermath
12-06-05, 12:35 PM
its most efficent to set the page files size to the same max and min and to put it on its own disk. edit: or partion

Captain Newbie
12-06-05, 01:53 PM
Waaaait a minute.

If you put it on another partition on the same disk as Windows, then you've got to seek to that other partition, and it would be just like having a fragmented page file. (Disk accessing some portion of Windows, then oops, time to page, time to seek to the other partition!)

I'd keep it on the same partition and contiguous.

BrutalDrew
12-06-05, 03:05 PM
That goes against everything I've ever heard or read, leaving windows manage a pagefile. Something to do with windows will resize the allocated amount ending up in overall slower performance due to the necessary expansion/contraction of the page file...

Just about everything you read is wrong when it comes to the pagefile. Most sites even say virtual memory and the pagefile are the same or that virtual memory is the sum of your pagefile and RAM.

Windows doesn't spend any effort resizing unless its necessary. If the initial size is high enough, it won't be necessary, thus it will not resize.

And resulting in fragmentation, making the paging process slower.

The pagefile would have to be extremely fragmented to effect performance. This is because Windows NEVER reads or writes more than 64 KBytes per buffer to the pagefile. Also, Windows almost never reads or writes the pagefile in sequential 64Kbyte chunks. So after reading or writing one such buffer it WILL have to move the heads, no matter how fragmented the pagefile is. These pagefile IOs will be interspersed with paging IOs to many other files, and non-paging IOs to many other files, too. In between ALL such IOs the heads will have to move anyway. This is why fragmentation of individual files matters far less than the defrag vendors want you to believe.

its most efficent to set the page files size to the same max and min and to put it on its own disk. edit: or partion

No, it isn't. If the initial size is large enough, it will never resize. So there is no harm in setting the max size larger. Also, putting the pagefile in a partition of its own is not a good idea. All it will do is decrease performance by increasing your average seeking distance. If you have one drive you want your OS, applications and pagefile all in the same partition.

darksparkz
12-06-05, 03:23 PM
Lots of different opinions, probably leaving it alone would work best, since that's probably what 98% of the people do.

Vyncennt
12-06-05, 03:33 PM
If you have one drive you want your OS, applications and pagefile all in the same partition.

Ok...taking that into consideration, what would you suggest if I have a rather small empty harddrive to play with as a spare? I do have a 3.5 Gig drive that I could slave in that would not have ANYTHING else except the pagefile on it. Would that be an effective solution? I currently run Windows and everything else on a plain-jane 80 gig with an empty 60 gig slave in

Thanks

VYnny

The_Jizzler
12-06-05, 03:48 PM
bad idea vyn. that 3.5gig you got is probably alot slower than your bigger drives. not to mention the fact you want to hook it in as a slave. can only acess one device at a time on paralell ide so bad idea as well. if your hell bent on a seperate page file, the best solution is to have a hdd as fast/faster than your OS hdd on a seperate ide channel as a master.. key is =or>than speed swap hdd, and seperate ide channels.

BrutalDrew
12-06-05, 03:58 PM
The_Jizzler is correct. The fact that the drive would be a slave defeats the purpose of even putting the pagefile on a separate drive in the first place.

Vyncennt
12-06-05, 04:06 PM
How bout this then: Take the spare 60 Gig drive (same speed as 80) and master it on the secondary IDE channel with the CDROM as a slave?

We're going theoretical now, seeing as I have two CD roms...lol

I was aware of the IDE channel limitation of accessing one device at a time, but didnt know if I would still get any improvements from a standalone pagefile.

Thanks for clearing things up for me =)

Vynny

K15
12-06-05, 07:00 PM
Just about everything you read is wrong when it comes to the pagefile. Most sites even say virtual memory and the pagefile are the same or that virtual memory is the sum of your pagefile and RAM.

Windows doesn't spend any effort resizing unless its necessary. If the initial size is high enough, it won't be necessary, thus it will not resize.



The pagefile would have to be extremely fragmented to effect performance. This is because Windows NEVER reads or writes more than 64 KBytes per buffer to the pagefile. Also, Windows almost never reads or writes the pagefile in sequential 64Kbyte chunks. So after reading or writing one such buffer it WILL have to move the heads, no matter how fragmented the pagefile is. These pagefile IOs will be interspersed with paging IOs to many other files, and non-paging IOs to many other files, too. In between ALL such IOs the heads will have to move anyway. This is why fragmentation of individual files matters far less than the defrag vendors want you to believe.



No, it isn't. If the initial size is large enough, it will never resize. So there is no harm in setting the max size larger. Also, putting the pagefile in a partition of its own is not a good idea. All it will do is decrease performance by increasing your average seeking distance. If you have one drive you want your OS, applications and pagefile all in the same partition.


He's saying let windows manage the page file is bad, (the "system managed size" option) since windows can't know how big to make the page file until the RAM starts filling up.
Anyhow, what is the difference between virtual memory and the page file? I've read a great number of technical books and technical sites, and virtual memory is the general term given to hard disk space being used as memory.
So then what is the difference? The page file settings in windows is even under a heading of "virtual memory" :shrug:

Seven7Thirty30
12-06-05, 07:08 PM
Before you confuse yourselves, read this from Microsoft's support page.

http://www.support.microsoft.com/default.aspx?scid=kb;en-us;555223&SD=tech

BrutalDrew
12-06-05, 08:47 PM
Anyhow, what is the difference between virtual memory and the page file? I've read a great number of technical books and technical sites, and virtual memory is the general term given to hard disk space being used as memory.So then what is the difference? The page file settings in windows is even under a heading of "virtual memory"

The term virtual memory includes several difference mechanisms. One of which involves using files on disk to store parts of virtual address space that won't all fit in RAM at the same time. The pagefile is only one of these files.

Captain Newbie
12-06-05, 09:19 PM
The term virtual memory includes several difference mechanisms. One of which involves using files on disk to store parts of virtual address space that won't all fit in RAM at the same time. The pagefile is only one of these files.
Virtual memory is a broad and sweeping term that (may) include any of the following--
1) Paging
2) Segmentation
3) Protection (which is a result of 1 and 2 along with other bits and bobs)
--and primarily involves the resolution of a logical address to a physical address.

What this is saying that, is in modern operating systems, an instruction that references the logical address 0xDEADBEEF may not actually address the *physical* 0xDEADBEEF, or at least not directly. The physical address will vary, depending on the particular model of memory allocation.

Memory is divided into pages (I ignore segmentation here since I don't like it) of some arbitrary page-size (on Linux x86, it's 4KiB), and applications may request pages. A table of pages is kept by the OS. It's a combination of the page number and the logical address that results in an actual physical address being generated. Also included in the page descriptor table are entries for whether or not the page is present in physical memory, as well as privelege levels and other bits.

One advantadge of a virtual memory system is that it's permissible to copy sections of memory from RAM to slower devices (read: hard drives) to free up physical RAM for applications who are running. The precise way that operating systems search for victims (to page out) is far beyond the scope of this forum. Suffice to say, if a process decides that it doesn't need any more time, or if you minimize (background) it, it's probably going to be paged out at some time or another in the immediate future if you're short on RAM.

And from the other direction...let's say that the application who wanted to reference a memory location (call it 0xDEADBEEF again for sake of argument) had recently had the page containing 0xDEADBEEF paged out. The OS will take over on the page fault, and load the appropriate page from the drive to RAM, swapping another page out as required.

This all happens very quickly, but there is still a tremendous penalty for page faults, since modern RAM has a nanosecond access time and even the fastest of hard drives have an access time on the order of milliseconds. This is why having as much physical RAM you can have is a good thing. (among other reasons :) )

K15
12-06-05, 11:11 PM
The term virtual memory includes several difference mechanisms. One of which involves using files on disk to store parts of virtual address space that won't all fit in RAM at the same time. The pagefile is only one of these files.


Ah ok, so the page file is part of virtual memory, but to say virtual memory does not necessarily mean page file...

K15
12-06-05, 11:12 PM
This all happens very quickly, but there is still a tremendous penalty for page faults, since modern RAM has a nanosecond access time and even the fastest of hard drives have an access time on the order of milliseconds. This is why having as much physical RAM you can have is a good thing. (among other reasons :) )


Ever had a computer with WAY too little ram? That constant HDD thrashing drives me mad. When the HDD is working but i'm not doing something, I have to know why! Same reason I don't like background AV scans or updates.

The_Jizzler
12-07-05, 12:25 AM
vyn, your last setup would be correct for what your trying to do, until you acess the cdrom on that ide and cut off the page file. its gotta be alone, unless you rarely use that cdrom, or else performance will suffer.

Captain Newbie
12-07-05, 12:50 AM
Ever had a computer with WAY too little ram? That constant HDD thrashing drives me mad. When the HDD is working but i'm not doing something, I have to know why! Same reason I don't like background AV scans or updates.
Yep. :( You run into page faults all the time, and all those msec penalties add up. Thrashing is the result.

aftermath
12-07-05, 01:51 PM
windows can handel how much memory?

aplications can address about 2 gigs of memory?

i happen to have a page disk thats a lot faster for writes than my raid 10 set

are hard disks cheep per gigabyte compared to say 10 years ago?

so i could afford to say set some spare for just that purpose?

ok i have a workstation not a pc but still nice fast disk for when u run out of much more expensive memorry seams a great idea, i dont even keep my tempory files on the windows disk they change size all the time and some times there not enven there :o !!

so if i have room for the extra 2 disks for paging and tempory files and since i have extra contolers and 1.5gb ram aint enougth i still think its faster. my spare temp disk space has drivers/office/installs etc and my page diisk has a partion for scratch files for music recoding or doesnt photoshope use that too? etc

idealy you want the drive on its own controler more than the chanel because two controlers can write directly to each other or from and two main memory symultainiusly

Captain Newbie
12-07-05, 02:19 PM
32-bit platforms as we know them now typically allow up to and including 2^32 bytes per segment (Four gigs). Windows NT (read: most every Windows system these days, since XP == NT with goodies) doesn't use segmentation at all, resulting in a flat 32-bit address space. (Until recently, that was more than enough for everyone except database and heavy applications.)

Windows does weird stuff and typically I believe applications are limited to 2GB of address space.

It should be noted that 48 logical and 40 physical address bits are available on the x86-32 and x86-64 platforms, and that Win64 takes advantadge of this to extend the address space to some large number.

JigPu
12-07-05, 03:25 PM
vyn, your last setup would be correct for what your trying to do, until you acess the cdrom on that ide and cut off the page file. its gotta be alone, unless you rarely use that cdrom, or else performance will suffer.
Most people don't use their CD-ROM drive nearly as much as their hard drive, so I wouldn't be too worried about that ;) Just about the only pagefile intenstive task involving CDs I can think of is loading a game, but most modern games wind up installing 90% of the data to load on the HD anyway (the CD is just used as an anti-piracy measure), so the performance hit should actually be less than keeping the pagefile on the same drive as the game.

JigPu

K15
12-07-05, 07:26 PM
windows can handel how much memory?

aplications can address about 2 gigs of memory?

i happen to have a page disk thats a lot faster for writes than my raid 10 set

are hard disks cheep per gigabyte compared to say 10 years ago?

so i could afford to say set some spare for just that purpose?

ok i have a workstation not a pc but still nice fast disk for when u run out of much more expensive memorry seams a great idea, i dont even keep my tempory files on the windows disk they change size all the time and some times there not enven there :o !!

so if i have room for the extra 2 disks for paging and tempory files and since i have extra contolers and 1.5gb ram aint enougth i still think its faster. my spare temp disk space has drivers/office/installs etc and my page diisk has a partion for scratch files for music recoding or doesnt photoshope use that too? etc

idealy you want the drive on its own controler more than the chanel because two controlers can write directly to each other or from and two main memory symultainiusly


I hope cost per GB is lower today. :eek:
Probably about $200-$400 10 years ago. Cost per GB on my drive now is about 60 cents :)

3DFlyer
12-07-05, 07:38 PM
I let windows manage my pagefile. Shutting it down can cause issues, and I have personally witnessed those issues. The best thing to keep max performance is to let windows manage it, and run a program called "pagedfrg" by Sysinternals. It's a free download, and helps performance. in fact it's a tweak i leanred of through the simulator community. If you've never ran it, run a benchmark, then run the program, and run the bencmakrk again and watch your score go up. It works. :)

RJARRRPCGP
12-09-05, 06:42 PM
The pagefile would have to be extremely fragmented to effect performance.

Maybe that's because you have a Raptor. :rolleyes:

Many people don't have 10,000 RPM or higher for HDDs. The random seeks are faster than 7,200 RPM HDDs, which many people including me have.

BrutalDrew
12-10-05, 06:26 AM
Maybe that's because you have a Raptor.

Many people don't have 10,000 RPM or higher for HDDs. The random seeks are faster than 7,200 RPM HDDs, which many people including me have.

Did you not read my post? I thought I summed it up pretty well.

This is because Windows NEVER reads or writes more than 64 KBytes per buffer to the pagefile. Also, Windows almost never reads or writes the pagefile in sequential 64Kbyte chunks. So after reading or writing one such buffer it WILL have to move the heads, no matter how fragmented the pagefile is. These pagefile IOs will be interspersed with paging IOs to many other files, and non-paging IOs to many other files, too. In between ALL such IOs the heads will have to move anyway. This is why fragmentation of individual files matters far less than the defrag vendors want you to believe.

The same thing goes for fragmentation in general. It is only neccessary in extreme cases because most I/O access is random not sequential, meaning sequentialness matters very little. If I read block 1, then block 20, what does it matter if the file is sequential? I will have to seek anyway. Most I/O is of that nature. The biggest major exception on a modern system is large data files, like music and movies. Just about everything else is read/write with primarily random I/O.

BTW, I don't have a Raptor...