Win7 pagefile

Clum

Clum

Clum

Soldato
Joined
7 Dec 2008
Posts
2,864
Location
Scottish Borders
Just a quick question regarding the w7 pagefile, as I've only a basic understanding of these nowadays.

I'm using a single hard disk with a 100GB partition ( C: ) for the OS install, and another 400GB partition ( D: ) for all my program files, storage ect.

At the moment, windows is set to a system managed pagefile on "C" and is disabled on the "D" drive. Is this the best setup already or should I be running a file on "D" as well? Seems to make sense to me to have one on both partitions seeing as the majority of files are already on "D" to start with.
 
A system managed pagefile is all one should ever have and on Vista/7 there is zero reason to change this default setting as it won't improve performance at all.
 
mikewebb said:
Unless you have a SSD I'd just let windows manage it for you
Click to expand...

.... and you should do the same for a SSD:

Should the pagefile be placed on SSDs?

Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.

In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that

Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.
In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.
Click to expand...

Source
 
Guys, not sure you're understanding my question. Of course I know that it should be system managed but what I'm asking is if I should have a system managed pagefile on both my "c" and "d" partitions, or solely on the "c"?

By default it is disabled on "d".
 
Clum said:
Guys, not sure you're understanding my question. Of course I know that it should be system managed but what I'm asking is if I should have a system managed pagefile on both my "c" and "d" partitions, or solely on the "c"?

By default it is disabled on "d".
Click to expand...

Yes and that's how it always should be, one PF on the OS partition only.
 
Not really.

A page file on the non-OS drive is better than one on the OS drive.

Likewise, two page files on separate drives is better than one. The kernel will load balance paging operations across both disks, depending upon I/O queue lengths (i.e. disk load).

There's not really any special rules for SSD drives either. Except that page files work best on SSD.
 
Surely not for normal day to day PC usage or general gaming where RAM capacity is never reached assuming the user has 4GB of RAM.

But if you're strapped for RAM and Windows has to resort to paging to disk for the remainder of the task requested then I guess you'd see a small benefit because Windows will page to the disk with the least activity and load balance as you say - that is of course assuming the user has exhausted their RAM capacity which would be quite unlikely today no? Especially on Windows 7.
 
Last edited:
mrk said:
Surely not for normal day to day PC usage or general gaming where RAM capacity is never reached assuming the user has 4GB of RAM.

But if you're strapped for RAM and Windows has to resort to paging to disk for the remainder of the task requested then I guess you'd see a small benefit because Windows will page to the disk with the least activity and load balance as you say - that is of course assuming the user has exhausted their RAM capacity which would be quite unlikely today no? Especially on Windows 7.
Click to expand...

Windows doesn't page just when it's run out of RAM, it also pages stuff out that has no business currently being in ram, or stuff that has been modified.
 
Environment paging like that isn't paged data that would result in the user seeing a marked boost in performance though. The only time you'd see a performance boost from a customised pagefile setup is when the pagefile is being actually used, not the day in day out standard paging as they're hardly taxing the harddrive at all.

Isn't this the whole point of Superfetch, to make memory management seamless and to eliminate the need for the end user to need to touch anything related to memory management - more Windows 7 focused than Vista but it still applies to the latter.

Edit*

I've read countless articles advising people on how to optimise their pagefiles in all my years of computing and support but have yet to see a definitive benchmark showing that there is a significant boost in performance from tweaking a Vista or 7 pagefile.

I would love to be shown otherwise and I'd tip my hat but I've just yet to see such comparisons.

And then the speed of today's hardware further lessens the need to tweak anything like what was needed in the past.
 
Last edited:
2 or 3 instances of Visual Studio and a SQL Server instance certainly cause some paging on 4GB RAM.

Define "day to day" I guess. The above is my day to day for 5 days a week at least.
 
That's quite specualised though, how many people run a few VS instances and SQL?!

Day to day as in some photo editing, maybe some dvd encoding or video conversion (everyone has a camera now or records their game to upload to youtube so need to convert). Multitasking etc.
 
Every time you minimize an application, the kernel will page the vast majority of the application out to disk (if it hadn't already done so).

That's not to say that it is guaranteed to read that data back from the page file when you restore/maximize the application again. Because chances are, providing your system is not low on memory or you haven't left it minimized for hours/days, then the 'invalidated' pages will still be in main memory and won't have been touched. They were simply temporarily put on the "potentially free if needed" pool. In this case the kernel can simply "recover" those pages by putting them back on the untouchable "allocated" pool.

That's why the page file is so important. Because it represents a "slightly dirty mirror image" of what is in main memory.

Sometimes people think it is analogous to an "overflow carpark" but that's not an accurate representation at all. It is actually more analogous to some sci-fi concept like a "parallel universe". Where things are mostly the same except that everybody is missing 1 finger and has 12 toes :p

So optimising the page file is still important, even today. Because today it is actually used even more than it was in the 1990's. Larger applications and more multi-tasking occurs on today's PCs than ever before. The difference between then and now is merely Windows 9x versus Windows NT. Win9x was built on top of MS-DOS, an OS that didn't support multi-tasking (or paging) natively. So Win9x hacked it onto the side. Windows NT's kernel was written by the same people as VMS from the days when DEC looked to be a big player of the future. VMS, as it's name suggests, was one of the first operating systems to really take the concept of virtual memory and run with it. Before VMS many operating systems just tacked virtual memory onto the side but didn't orbit around it. Windows NT is a direct decendant of VMS and this is why NT is so damn good at virtual memory. To be honest, there haven't been all that many significant changes to it since Windows 2000. So I'm not sure where all of a sudden this praise for it is coming from now that Windows 7 is here.
 
+1 to what has been said, also you shouldn't put pagefiles on multiple partitions on the same drive
 
I just leave page file as sytem managed, I'm sure MS know better than I do how to manage a page file, I have a 10GB partition on a seperate HDD to the OS exclusively for the page file and leave it at that.
 
You must log in or register to reply here.
Back
Top Bottom