SuperFetch: How it Works & Myths
Linked by Thom Holwerda on Mon 11th May 2009 20:43 UTC
Windows SuperFetch is a technology in Windows Vista and onwards that is often misunderstood. I decided to delve into this technology to see what it is all about, and to dispel some of the myths surrounding this feature.
E-mail Print r 3   · Read More · 79 Comment(s) http://osne.ws/gkf
Permalink for comment 363145
To read all comments associated with this story, please click here.
malxau
Member since:
2005-12-04

...If you don't need it, no harm done - 'unloading' doesn't exist. Apps start as fast as without superfetch OR faster. Never slower.


This story is full of comments by people indicating that it can be slower. Note that if an app requests 200Mb RAM, the memory manager still needs to walk along the standby list discarding prefetch data page-by-page, so it's more accurate to say "SF data is not written back to the pagefile", but it still needs to be unloaded.

if the IO priority system is screwed, the reading superfech does COULD interfere with other activity. Depends on the quality of the kernel's management of priorities. No idea if this is an issue at all, I doubt it, but it is possible.


If the priority system were not screwed, it could still be bad. In theory, low priority IOs should be issued to disk on a 1-in-20 basis when normal priority IO exists. If your normal pri IO is sequential, that low priority IO can still trigger a seek and slow it down.

And yes, IO priorities are far from perfect. In Vista, no priority boosting was performed if a regular priority thread was waiting on activity performed by a low priority thread. It could stall on a collided pagefault (needs the data prefetch is fetching) or on any lock in the IO path (prefetch has a lock held, issued low pri IO that takes seconds to complete, and the foreground apps wait for the lock.)

In Win7 boosting is implemented and will be performed if a normal pri thread waits on many common locks (but not all) held by a low pri thread.

superfech uses resources while your PC wouldn't have been doing anything if it weren't running. Bad for powerusage = environment and probably slightly bad for the lifespan of your hardware.


That's inherent in the design of SF (use background cycles to load things.)

It might be true that the first issue I noted is actually real - but then the MS engineers writing this would've been rather stupid to forget about making the priority system work properly.


(Disclaimer: I am an MS engineer who worked on making the priority system work properly, but have not worked on SF itself.)

To be fair to the SF crew, Vista was finished under considerable time pressure. Changing every lock in the IO path to be low priority aware is a huge job. They were faced with the choice of shipping with no IO priority, shipping with IO priority in the disk scheduler that can invert in higher levels, or spending years making it perfect. They chose the middle option, presumably as a compromise. It still gives some benefit, but also has some inversion problems. Their choice doesn't make them stupid - it made sense at the time. Resources are always finite.

Reply Parent Score: 1