WinXP 'System Cache'

[Jexx]

Ok, seen a lot of posts on the internet about things like this but none that answer my question. Most of the posts seem to be centered around the system cache settings like the ones in the advaced tab near the page file settings. The one I'm looking at is the one in Task Manager, so before posting please take a look.

My question is anybody got and understanding of what exactly this is and what effects it has. I have a system with 1GB of memory and I am constantly seeing sizes of over 500mb, sometimes almost 700mb. Without knowing exactly what it is I am unsure as to the effect it has on my system.

 

[Nothinman]

It's where the system caches things for faster access, mainly filesystem data. A high system cache value means a lot of data from your hard drive is being cached in memory which means your hard disk is doing less work, which means there's less latency for accessing the data.

 

[Bozo]

Windows 2000 allocates a portion of the virtual memory in your system to the file system cache. The file system cache is a subset of the memory system that retains recently used information for quick access. The size of the cache depends on the amount of physical memory installed and the memory required for applications. The operating system dynamically adjusts the size of the cache as needed, sharing memory optimally between process working sets and the system cache.

From here http://www.microsoft.com/resources/docu...er/reskit/en-us/core/fnec_evl_ACKS.asp

Bozo

 

[Jexx]

Sorry but I'm not convinced, if it applies to Disk caching then it would be a total waste of time. as on my system I get :

Total 1047992
Available 729176
System Cache 763312

Which would mean that the disk cache is being paged out to the swap file, which would make no sence at all.

And I appologise for not saying but this is on WinXP Pro SP2

 

[Nothinman]

It's not paged out to the pagefile, it's marked available because it can be reused without much effort. Any data that's in the system cache and 'clean' can be discarded because if needed it will just be paged back in from it's place on disk.

 

[Jexx]

Ah now I see, make more sence, the only other question is I have 248MB of swap file in use according to the same screen, why so much dumped to disk (espcially when you consider that adding the PF Usage to the System Cache gives you the total memory) ?

 

[Nothinman]

PF Usage doesn't mean pagefile usage, oddly. It counts reservations as well as real usage, so the numbers are usually extremely exxagerated.

If you're really interested, get a copy of Inside Windows. It supposedly explains how all of the internal subsystems of Windows work.

 

[VirtualLarry]

Originally posted by: Nothinman
PF Usage doesn't mean pagefile usage, oddly. It counts reservations as well as real usage, so the numbers are usually extremely exxagerated.

Are you saying that uncommitted VM allocations are accounted for as "PF Usage" still? That doesn't make a lot of sense, but then again, this is MS we're talking about.

Are you sure that it isn't actual committed VM pages, but possibly the overall value is slightly exaggerated, as it might not make adjustments to the accounted value based on per-process overlap, for shared mappings with the same physical backing-store for those pages?

Either way, the number wouldn't be exact, but the reasoning behind that would be a little different.

 

[Nothinman]

Are you saying that uncommitted VM allocations are accounted for as "PF Usage" still?

That's my understanding of it.

 

[kylef]

If you'll notice: in XP's Task Manager, the "PF Usage" is the same as "Commit Charge - Total." The only difference is that "PF Ussage" is reported in MB, "Commit Charge" in KB.

So the root of the problem here is that you're being misled by an unfortunate name choice, which was a poor compromise.

Prior to XP, Task Manager labeled this bar graph "Mem Usage." This name was most likely picked because "Commit Charge" is an arcane, unfamiliar term for most people. Unfortunately, because it underreports true VM usage in most cases (it does not tally shared pages, read-only mapped files, etc.), it was too misleading to call it "Mem Usage". So the name was changed to "PF Usage" in XP, which is only slightly more accurate. The only problem now is that Commit Charge does NOT report the current page file usage, as you might expect.

Remember, think of "commit charge" as the total amount of data that would need to be written to the Paging file if all processes were swapped out of memory. This includes all private VM used by apps as well as drivers and the pageable heap in the kernel.

Originally posted by: VirtualLarry
Are you saying that uncommitted VM allocations are accounted for as "PF Usage" still? That doesn't make a lot of sense, but then again, this is MS we're talking about.

No. Only committed pages count.

Are you sure that it isn't actual committed VM pages, but possibly the overall value is slightly exaggerated, as it might not make adjustments to the accounted value based on per-process overlap, for shared mappings with the same physical backing-store for those pages?

Shared pages are not counted. Neither are executable images or other read-only mapped files.

 

[Nothinman]

No. Only committed pages count.

Do you mean committed to memory or commited to the pagefile?

 

[kylef]

Originally posted by: Nothinman

No. Only committed pages count.

Do you mean committed to memory or commited to the pagefile?

Committed to memory. As in, the app calls the C malloc function or the C++ new operator. Or, if handling memory itself using the Win32 heap methods, perhaps it calls VirtualAlloc( NULL, size, MEM_COMMIT, PAGE_READWRITE).

Since malloc() and new are written using VirtualAlloc(), it's all basically the same thing.

The Commit Charge tally is incremented whenever virtual memory in an app or the kernel is "committed" to physical resources. Some of the pages in the Commit Charge may be in RAM, and some may be in the pagefile.

 

[Nothinman]

Committed to memory

That's what I thought. Because I believe VirtualLarry meant commited to the pagefile

 

[kylef]

Originally posted by: Nothinman

Committed to memory

That's what I thought. Because I believe VirtualLarry meant commited to the pagefile

Well, the term "commit" in Windows has always meant "commit to physical storage."

That could mean to RAM or to Disk, depending on the current state of the Memory Manager.

It's important to use precise terminology when discussing Virtual Memory: it's a complicated enough subject already without semantics getting in the way.

 

[Nothinman]

It's important to use precise terminology when discussing Virtual Memory: it's a complicated enough subject already without semantics getting in the way.

No doubt. You mean like the many mislabled tools that come with Windows? =)

 

[kylef]

Originally posted by: Nothinman

It's important to use precise terminology when discussing Virtual Memory: it's a complicated enough subject already without semantics getting in the way.

No doubt. You mean like the many mislabled tools that come with Windows? =)

Point taken. That's why I cruise these forums looking for confused souls.

 

[Nothinman]

I also don't see why the lable on taskmgr was changed from Commit Charge to PF Usage. Even if it's slightly, technically more accurate all it does is make people think their pagefile is being overused and try to figure out a way to tweak it so that number is smaller. Mem Usage would have been a better label IMO because even though it's larger than the what's really in use, it tells the user that it's talking about physical memory usage and not pagefile usage, so that we could avoid all of the "OMG I have 12G memory and Windows is using 4G of my pagefile, why does windows suck so bad?!?!?!?!" posts.

 

[VirtualLarry]

Originally posted by: Nothinman

Committed to memory

That's what I thought. Because I believe VirtualLarry meant commited to the pagefile

Traditionally, in VM systems, "committed" simply means that actual resources are allocated and mapped into VM space. Whether those resources are currently residing in RAM or the pagefile is mostly irrelevant. The opposite of commited pages, would be process-level VM address-space allocations (which would cause PTE allocations by the system on behalf of that process, behind the scenes), which need not necessarily be mapped to anything. They could eventually be used to map a file (using already-allocated resources in terms of the system file cache), or a hardware address range (thus not allocating any physical system RAM or pagefile space), etc. (Or even an entire other process running in the system, given sufficient access-rights.)

It sounded like you were suggesting that the "PF Usage" accounting, was including uncommited VM address allocations, which didn't make a lot of sense to me. My question was more pointed at, if it was a count of committed VM, then how were shared page mappings accounted for? Because those could make the displayed number inaccurate as well.

 

[kylef]

Originally posted by: Nothinman
...so that we could avoid all of the "OMG I have 12G memory and Windows is using 4G of my pagefile, why does windows suck so bad?!?!?!?!" posts.

I'll pass along the feedback, but I've got the (unsubstantiated) feeling that Task Manager is probably not on the list of features getting an overhaul in LH.

 

[Nothinman]

I'll pass along the feedback, but I've got the (unsubstantiated) feeling that Task Manager is probably not on the list of features getting an overhaul in LH.

If it won't be fixed until LH then it's irrelevant anyway, that'll leave us with another ~5 years of crying based on the XP label and it'll be ingrained into another generation's mind that Pagefile = VM and Windows sucks at memory usage because it uses a ton of pagefile no matter how much memory you have.