Windows 7 Pagefile/Superfetch/ReadyBoot discussion

[Udedenkz]

I am not sure about 7, but before 7, you could do this, (if you have a PF)

1. Open A Bunch Of Applications (1GB minimum )

2. Minimize Them All

3. Let Computer Idle Some Time

4. Then Quickly Maximize all of them / start using them

5. Watch your computer slow down almost to a halt

This was because Steps 3 & 4, the idling applications were moved to the Page File to save RAM. Therefore, whence you started using them, Windows did not have them in RAM and therefore - it had to get multiple GBs of data from the slowest device in the modern computer (Hard Drive) as fast as possible. Ow.

[StarLion]

I am not sure about 7, but before 7, you could do this, (if you have a PF)

1. Open A Bunch Of Applications (1GB minimum )

2. Minimize Them All

3. Let Computer Idle Some Time

4. Then Quickly Maximize all of them / start using them

5. Watch your computer slow down almost to a halt

This was because Steps 3 & 4, the idling applications were moved to the Page File to save RAM. Therefore, whence you started using them, Windows did not have them in RAM and therefore - it had to get multiple GBs of data from the slowest device in the modern computer (Hard Drive) as fast as possible. Ow.

You...still have no idea what you're talking about.

Windows will only send the entirety of a minimized (but running) application to the pagefile if you're close to running out of resources. If you have plenty of RAM left, running applications are left in RAM.

[Udedenkz]

This might be a bit offtopic, but,

Does anyone know about the other keys in,

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\ ?

Is there a documentation any where? If one is readyboot/st, what are the other ones?

Thanks.

[Joe User]

This might be a bit offtopic, but,

Does anyone know about the other keys in,

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\ ?

Is there a documentation any where? If one is readyboot/st, what are the other ones?

Thanks.

Messing around in WMI is usually a quick path to re-installing windows. That being said, I would check out MSDN or Technet for detailed info on playing around with the Windows Managment Interface.

[Joe User]

1) Everything in my post above is correct

Sorry, I've been at this since Windows 3.0, you're way off on the pagefile thing.

There are some valid situations for not using a pagefile, and I can safely say 99% of them would not be important to users here. So, unless the end user is creating an information kiosk or an ATM, leave the pagefile on.

Simply: To say Windows can't run without a pagefile is false. Turning off the pagefile is not recommended and can lead to situations where you wind up in safe mode to turn it back on. It will not destroy your Windows install.

[+allan MVC]

I said I wouldn't post again in this thread, but if I'm going to be "quoted" I'd at least like the quote to be correct. Let me make myself clear and then I won't bother to post again in this otherwise pointless thread.

I never said Windows can't run without a pagefile. I did say the OS was designed to page and it always WILL page. The difference is whether or not it pages to virtual memory in a designated pagefile or if it has to create its own space on the drive without user knowledge or intervention so it can page as needed. Of course a system can run without a designated pagefile (sometimes fairly smoothly, often not so much) - but there is absolutely, positively no logical reason any TYPICAL user should ever disable the pagefile. Okay, that's it for me. Back to letting the much more knowledgeable people continue to spread their - ahem - knowledge.

[hdood]

I never said Windows can't run without a pagefile. I did say the OS was designed to page and it always WILL page.

Obviously Windows will always page, as the whole concept of paging is integral to any virtual memory-based OS. The ability to read and write pages to disk, however, is an optional feature.

The difference is whether or not it pages to virtual memory in a designated pagefile or if it has to create its own space on the drive without user knowledge or intervention so it can page as needed.

Here is where you've got it completely wrong. If you disable the page file, Windows will not create one. Since no page file exists, it will never write pages to disk. Ever. It doesn't happen. Without a pagefile, everything will be located in physical RAM (the exception being things that can be re-read from the executable image on disk.) This will obviously still generate page faults, but they will never have to be resolved from disk. I don't understand what kind of scenario you are envisioning where Windows must be able to write a page to disk. You have been told this before, and you have been asked to provide a source or explanation for this claim of yours, something you haven't done. I respectfully ask that you either do so right now and correct me, or recognize your mistake.

I will also again repeat what the older Task Manager means when it says "Page File." It is the commit charge of the system. In other words, the total amount of memory the system has promised processes. It says nothing about where the pages are located. The highest possible commit charge is the amount of available RAM plus the amount of available page file space. Any requests above this will simply be denied. If you absolutely must tie it to the page file, you can think of it as the amount of space it would require if all pages were written to disk right now.

For kernel memory, "paged" simply means data that could be written to disk if there was a need.

When it counts "page faults," it's counting both soft and hard faults, and probably even memory-mapped files (if you run Winamp for instance, this is how it reads files.)

[Joe User]

I said I wouldn't post again in this thread, but if I'm going to be "quoted" I'd at least like the quote to be correct. Let me make myself clear and then I won't bother to post again in this otherwise pointless thread.

I never said Windows can't run without a pagefile. I did say the OS was designed to page and it always WILL page. The difference is whether or not it pages to virtual memory in a designated pagefile or if it has to create its own space on the drive without user knowledge or intervention so it can page as needed. Of course a system can run without a designated pagefile (sometimes fairly smoothly, often not so much) - but there is absolutely, positively no logical reason any TYPICAL user should ever disable the pagefile. Okay, that's it for me. Back to letting the much more knowledgeable people continue to spread their - ahem - knowledge.

Sorry, I was reponding to point 1 in your post but the last paragraph wasn't a direct reply to you. Chalk that up to bad formatting on my part.

[+Frank B. Subscriber²]

Understanding the Windows Pagefile and Why You Shouldn't Disable It

</thread>

[Udedenkz]

As we've seen, the only tangible benefit of disabling the pagefile is that restoring minimized applications you haven't used in a while is going to be faster. This comes at the price of not being able to actually use all your RAM for fear of your applications crashing and burning once you hit the limit, and experiencing a lot of weird system issues in certain applications. "

The vast majority of users should never disable the pagefile or mess with the pagefile settings—just let Windows deal with the pagefile and use the available RAM for file caching, processes, and Superfetch. If you really want to speed up your PC, your best options are these:

* Upgrade your RAM.

* Clean off the crapware—the biggest cause of system slowdown.

* Switch to Microsoft Security Essentials and stop paying for bloated Windows security packages.

* Windows 7 handles multi-tasking much better than Windows XP did.

[Guest xiphi]

So, you agree that disabling the pagefile is a bad idea?

[Xilo]

In the long run, there's absolutely zero benefit to disabling it. So why bother?

[Udedenkz]

Can someone confirm that Life Hacker is right about minimized / idle applications being moved to the PF?

[x-byte]

When you choose the option that says no paging file (that is the actual name of it), it literally means that.

No it's not. It's there so you can allocate the page file to another location. Not disabling it all together.

Some of you should really learn how a OS works before jumping to these conclusions. Most of, if not all, tweaking software is useless and a waste of time. And if anything should only be used by experienced users.

Edited December 14, 2009 by x-byte

[Xilo]

Like defragging ram? :laugh:

[zhangm Supervisor]

Like defragging ram? :laugh:

Don't worry about defragging your RAM, just download some more.

http://www.downloadmoreram.net/

Also, who saw this one coming? :rolleyes:

https://www.neowin.net/forum/index.php?showtopic=855244

[Brandon Live Veteran]

The only implication of my expectations is that they be overall faster than that SSD you have there.

That SSD has 120MB/s read speeds, 40MB/s write speeds, and 0.2ms access times (with spikes over 100ms if the drive is loaded).

The only thing that drive has going for it is sequential read speed, which isn't the most important factor for making a system responsive. In fact, the access times on that SSD can become so poor due to the stuttering issue, that it reduces your effective read speed by more than half.

This is incorrect. SSDs accel at random I/O. Random reads in particular are always fast. What "stuttering issue" are you referring to? If you're referring to the problem some SSDs (i.e. cheap / older ones) had with random writes when full, that problem has been solved. Newer Intel or Indilinx-based SSDs have firmware which prevents this problem, and uses Trim to avoid overhead on writes when the disk is near full. Further, it only affected random writes, not reads. Reads are by definition always consistently quick on SSDs.

Lets say you have a hard disk with a 10ms access time and an 80MB/s read speed. Such a hard disk can load 1MB in 0.0225 seconds.

Lets say you catch your SSD when it's writing anything to the drive. This means the drive has 100+ms access times (due to the stuttering issue) and 120MB/s read speeds. Reading 1MB from the drive takes 0.1083 seconds

Reading 1MB from the SSD took almost 1/10th of a second longer than the hard disk, even though the SSD has faster read speeds!

This makes no sense, unless you're talking about one of those cheapo SSDs in some netbooks. I thought we were talking about an X25-M, which will blow away any hard drive in random I/O any day of the week.

Nope, just telling you the facts about it. Sorry if you don't like what you're hearing, not my fault you purchased it.

As I explained above, raw sequential read performance isn't everything. Access times can make or break a drive's performance.

Which is why SSDs represent such a substantial leap forward in responsiveness.

[hdood]

No it's not. It's there so you can allocate the page file to another location. Not disabling it all together.

Some of you should really learn how a OS works before jumping to these conclusions.

Selecting it disables the page file completely. That is what the option does. No more, no less. For the last time, I'm not saying that anyone should disable the page file, I am simply pointing out the following two incorrect claims made by allan:

1) Windows creates page files even if you disable them, and

2) Windows is constantly accessing the page file (to the point of it being noticeable, in fact)

If you think it doesn't matter, then you should ask yourself where nonsensical concepts like putting a page file on a RAM disk to improve performance came from. They came from misconceptions spread by people like allan.

Again, this is all I'm pointing out. I am not saying that people should go disable their page file (except for the guy who insisted he wanted to, and in that case there's no point in arguing with someone who's already made their mind up, just let them do what they want.) For the average system the cons far outweigh the pros, but this does not make allan's claims correct. It's unbelievable that you don't get this.

[Brandon Live Veteran]

1) Everything in my post above is correct

2) I will now gracefully bow out of this thread and allow all the rest of the experts to spread their, umm, knowledge

Actually it was not. You can absolutely disable all page file creation in Windows.

But you shouldn't.

I never said Windows can't run without a pagefile. I did say the OS was designed to page and it always WILL page. The difference is whether or not it pages to virtual memory in a designated pagefile or if it has to create its own space on the drive without user knowledge or intervention so it can page as needed. Of course a system can run without a designated pagefile (sometimes fairly smoothly, often not so much) - but there is absolutely, positively no logical reason any TYPICAL user should ever disable the pagefile. Okay, that's it for me. Back to letting the much more knowledgeable people continue to spread their - ahem - knowledge.

No such mechanism exists. If there's no page file, pages will never be swapped to disk...

[Brandon Live Veteran]

Obviously Windows will always page, as the whole concept of paging is integral to any virtual memory-based OS. The ability to read and write pages to disk, however, is an optional feature.

Here is where you've got it completely wrong. If you disable the page file, Windows will not create one. Since no page file exists, it will never write pages to disk. Ever. It doesn't happen. Without a pagefile, everything will be located in physical RAM (the exception being things that can be re-read from the executable image on disk.) This will obviously still generate page faults, but they will never have to be resolved from disk. I don't understand what kind of scenario you are envisioning where Windows must be able to write a page to disk. You have been told this before, and you have been asked to provide a source or explanation for this claim of yours, something you haven't done. I respectfully ask that you either do so right now and correct me, or recognize your mistake.

I will also again repeat what the older Task Manager means when it says "Page File." It is the commit charge of the system. In other words, the total amount of memory the system has promised processes. It says nothing about where the pages are located. The highest possible commit charge is the amount of available RAM plus the amount of available page file space. Any requests above this will simply be denied. If you absolutely must tie it to the page file, you can think of it as the amount of space it would require if all pages were written to disk right now.

For kernel memory, "paged" simply means data that could be written to disk if there was a need.

When it counts "page faults," it's counting both soft and hard faults, and probably even memory-mapped files (if you run Winamp for instance, this is how it reads files.)

This is all, as far as I can see, correct.

"Paged" for kernel memory means it is part of the "paged pool." The paged pool is kernel memory which can be paged to disk (if there's a page file). The non-paged pool is a section of kernel memory which can never be paged to disk under any circumstances. In Windows 7, this area is smaller, so that more infrequently used pages can be swapped to the disk, making more physical memory available to applications.

A "page fault" is simply what happens any time something is requested which isn't currently in RAM. When you load an application, lots of hard faults are expected to occur since the binaries and data for that application aren't in RAM... Despite the name, a "page fault" is not an error condition and is completely expected.

The old "Page file" readout in Task Manager was horribly named. In Windows 7 the label is now "Commit" which more accurately describes the number being reported. As stated, the first number is the total sum of all virtual memory allocations (regardless of their backing store, whether it's RAM, memory mapping, page file, etc) - the larger of the two numbers essentially reflects total RAM + total page file size.

[Brandon Live Veteran]

Can someone confirm that Life Hacker is right about minimized / idle applications being moved to the PF?

They are swapped to disk if they are unused and other applications are used which use up your available RAM. This is the entire point of the page file.

In Windows XP and earlier, apps could get paged to the disk more aggressively since these OSes were not really built for huge amounts of RAM, and things like running a screensaver or playing a game could result in minimized / idle applications getting pushed to the page file. Then when you restore them, a lot of data gets paged back into memory before they're responsive.

Vista and Win7 don't suffer from this problem for a variety of reasons.

First, they're very hesitant about paging since disks are slow and RAM is more plentiful these days.

Second, they have SuperFetch which watches for RAM to become free, and pulls pages back into RAM from the pagefile before they're needed. So if you quit a game that caused your minimized apps to be paged out to disk, SuperFetch will begin pulling that stuff back into RAM in the background, so you'll never notice the effect.

Finally, the OS is smarter about not paging out OS components, and lots of window manager, memory manager, and graphics stack changes have removed the problem of the whole system becoming unresponsive when paging an application back into memory.

On XP there may have been some advantage for large memory systems to disable the page file, albeit with some added risk. But nowadays there's no point at all.

[x-byte]

Selecting it disables the page file completely. That is what the option does. No more, no less. For the last time, I'm not saying that anyone should disable the page file, I am simply pointing out the following two incorrect claims made by allan:

1) Windows creates page files even if you disable them, and

2) Windows is constantly accessing the page file (to the point of it being noticeable, in fact)

If you think it doesn't matter, then you should ask yourself where nonsensical concepts like putting a page file on a RAM disk to improve performance came from. They came from misconceptions spread by people like allan.

Again, this is all I'm pointing out. I am not saying that people should go disable their page file (except for the guy who insisted he wanted to, and in that case there's no point in arguing with someone who's already made their mind up, just let them do what they want.) For the average system the cons far outweigh the pros, but this does not make allan's claims correct. It's unbelievable that you don't get this.

That wasn't my point. Just because the option is there for disabling the page file , it's not there to be disabled. Just so you can remove it from the current disk and set it for another. Doing this improves performance a little. Especially if it's on another physical disk (and faster).

[StarLion]

The only implication of my expectations is that they be overall faster than that SSD you have there.

That SSD has 120MB/s read speeds, 40MB/s write speeds, and 0.2ms access times (with spikes over 100ms if the drive is loaded).

The only thing that drive has going for it is sequential read speed, which isn't the most important factor for making a system responsive. In fact, the access times on that SSD can become so poor due to the stuttering issue, that it reduces your effective read speed by more than half.

This is incorrect. SSDs accel at random I/O. Random reads in particular are always fast. What "stuttering issue" are you referring to? If you're referring to the problem some SSDs (i.e. cheap / older ones) had with random writes when full, that problem has been solved. Newer Intel or Indilinx-based SSDs have firmware which prevents this problem, and uses Trim to avoid overhead on writes when the disk is near full. Further, it only affected random writes, not reads. Reads are by definition always consistently quick on SSDs.

We were talking about Udedenkz's very slow first generation SSD (which still has the stuttering issue).

Stuttering kicks in if you attempt to do a moderate number of random writes at once. Write speed goes down the toilet, and access times go through the roof. This type of stuttering is due to a problem with the drive controller itself, and has nothing to do with free space or the TRIM command (that's a whole other issue). The first gen J-Micron flash controller chips would become overloaded and performance would simply tank out of nowhere.

Newer SSD's have this fixed, but we weren't talking about newer SSD's... so in this instance, what I said was correct. Sorry if you missed the context.

Lets say you have a hard disk with a 10ms access time and an 80MB/s read speed. Such a hard disk can load 1MB in 0.0225 seconds.

Lets say you catch your SSD when it's writing anything to the drive. This means the drive has 100+ms access times (due to the stuttering issue) and 120MB/s read speeds. Reading 1MB from the drive takes 0.1083 seconds

Reading 1MB from the SSD took almost 1/10th of a second longer than the hard disk, even though the SSD has faster read speeds!

This makes no sense, unless you're talking about one of those cheapo SSDs in some netbooks. I thought we were talking about an X25-M, which will blow away any hard drive in random I/O any day of the week.

When did we ever say X-25M? I was responding to Udedenkz who very clearly stated he had an old SSD with the stuttering problem. It's quite easy for a hard disk to blow away the performance of his particular drive under a number of circumstances.

As I explained above, raw sequential read performance isn't everything. Access times can make or break a drive's performance.

Which is why SSDs represent such a substantial leap forward in responsiveness.

New ones do, but the first gen ones like Udedenkz has are pretty crappy all-around. The stuttering problem can create access times so high, that you're better off with a hard disk.

Edited December 14, 2009 by StarLion

[Udedenkz]

Thanks for that explanation.

Speaking of SSDs, if W7 detects one, W7 turns of defrag, superfetch but it also enables some special write mode specifically to help SSDs. In higher version of W7 with group policy editor, I could enable this mode to -supposedly- enhance performance / writes. How do I manually turn that on in Home Premium? I am not getting any stuttering issues at all, but still it would be nice to do this.

[Chrysalis]

Which is why SSDs represent such a substantial leap forward in responsiveness.

I hate it when review sites only check sequential read speed and ignore everything else. To me access times are prime and read speeds secondary. In fact I would put drive reliability above read speeds as well, so I wont be buying another samsung for sure.