First of all, I think we can all agree that the original poster was confused about the "PF Usage" bar graph in the Performance tab of Task Manager. He thought that meant Windows was literally using that much space in the pagefile. It is not. To my knowledge, there is no easy way to figure out exactly how much of the Pagefile is actually in use at any given time. Task Manager certainly doesn't show this, and neither does Perfmon. If anyone knows of an easy way, please enlighten me. I'll do some research on the subject and try to get back to everyone too.
Originally posted by: Phoenix86
I never really though about exes and libs being put into the PF, it makes perfect sense to use the file on disk instead of creating another copy in the PF... Guess that book has the best answers, as it's been mentioned in other threads.
It doesn't... When we say that mapped files are "paged to disk", we mean simply that they are written back to their original storage location (the disk file itself, NOT the pagefile). This is true for ANY file I/O access in Windows, including both EXEs and regular files. Your pagefile does not contain memory-mapped mapped files. Your System cache does. When a page in the cache needs to be flushed to disk, then the Cache Manager figures out how to write it back to disk: to the disk file if it's a memory-mapped file, or to the pagefile if it's just a random dirty page from some process.
I guess you mean a file just for memory dumps? Sure it might happen but I'm sure it's not high on their list of priorities and at the earliest it won't happen until Longhorn.
Yes, that's exactly what I mean. Hmm, I'll have to suggest that.
No, there is a reason dumps are written to the pagefile. It is mounted specially by the OS so that file system filter drivers (such as virus scanners) play no part in accessing it. That way, if kernel memory is corrupted, it increases the chances that a dumpfile will be written to disk correctly. (Imagine if the file system filter driver were the cause of the system crash in the first place: you'd have a problem trying to write the dump file through the file system, wouldn't you? That's the advantage of the pagefile.)
Third, who says VMM is 100% effecient? Not me. As I stated above, I have seen systems page to and from disk when there is absolutly no reason to.
Again: paging to and from disk can be two different things: 1) Pagefile activity and 2) File cache activity. If you use Perfmon to track Page faults/sec, the faults are triggered by ALL reads to memory-mapped files by any process on your system. Since all file I/O is implemented as memory-mapped files behind the scenes, that means that ALL file I/O reads that are cache misses show up as a system page faults! (Note that unless the file is explicitly memory-mapped by a process, the process is not charged with the page fault.)
In other words, there is a good chance that the "disk activity" you're seeing is not Pagefile activity at all, but simply Cache Manager activity.
That said, WindowsXP has lots of background services running (many under the "svchost.exe" banner) that can occasionally use up lots of RAM temporarily. The Cache Manager ALWAYS has a good reason to evict pages to the pagefile. And it always attempts to evict pages in LRU (least recently used) order to minimize the resulting performance penalty.
Because, and here's a bit of speculation based on experience, it's trying to keep as much RAM free as possible. If you do need it, it's available. What it doesn't know is the limits of the system.
Yes, the Cache Manager does perform some "balancing" to keep some pages on the free list for programs that request memory. But it doesn't do this randomly, and it absolutely knows what the limits of the system are. I will do some research to find out what the "balancing" criteria are.
The PF isn't cache, it's a poor substitute. Cache supposed to be faster than the component it's caching. IE, HDDs cache is faster than the HDD. L1-2-3 cache is faster than RAM. Yet, when applied to the OS, the HDD caches RAM.
Hmm... based on that statement, it doesn't sound like you understand the concept of a memory hierarchy. Every component in a memory hierarchy "caches" the lower-level hierarchy. Some of the levels are exclusive (or "orthogonal") while others replicate everything in the higher levels ("inclusive").
The top level is CPU Registers. The second level is L1 cache. The middle levels are the remaining L? caches (L2, L3, L4...). AMD, for instance, uses an orthogonal L2 cache, while Intel does not: it's implementation-specific. Next you get to system RAM. System RAM is always inclusive; i.e., you never see something higher in the cache hierarchy that isn't also stored in RAM. Finally, you get to disk, which is orthogonal: it is ONLY used when there isn't enough room in the higher levels to store all data.
So your claim that in the OS "the HDD caches RAM" is simply not correct. The
higher levels are caching the lower levels, throughout the whole computer. The pagefile is only used when there isn't enough room in System RAM to store all of the data requested by processes. It's used as a "backup", not a cache. The System Cache Manager determines when it must flush some pages to the pagefile, and it always has good reasons to do so.
Does that clear things up at all? Or have I simply opened up more cans of worms?
Facebook
Twitter