0

Saw this thread but I believe it does not fully answer my question so here goes. I am on Windows 8 Enterprise, 4 Gb RAM on board, pagefile enabled. I am looking at my performance indicators and I see that current commit charge is 4.14 Gb while the amount of used physical memory is 2.43 Gb plus another 919 Mb are used for standby (i.e. the file cache etc.)

But why is it so? If I understand the notion of commit charge correctly, it basically means the current demand for RAM from all the running apps and services. Then, it looks completely obscure to me why would Windows allocate that much memory for the cache, at the same time forcing a part of the running apps to be swapped out to the pagefile? Wouldn't it be more reasonable to purge the most of the cache to give the running apps as much RAM as possible and re-fill the cache as soon as more free RAM becomes available?

DmytroL
  • 101

1 Answers1

0

No, commit charge is not the "current demand for RAM". It's the current demand for pagefile-backed virtual address space (total across all processes, plus some system-wide allocations).

It is very common for only a portion of this to have been referenced. It would be completely silly to tie up RAM for parts of virtual address space that haven't been referenced yet (unless you have some way of knowing what will be referenced in the future).

Allocating RAM to the cache is, on the other hand, done because there is good evidence that stuff being cached is likely to be needed again soon (in most cases, the evidence is that it was referenced recently). So why not keep it in RAM?

Also: RAM is not "allocated" to the cache on any sort of permanent basis. If other things need more RAM, the cache's RAM will be shrunk, if necessary, to accommodate them.

There is almost never enough RAM for all processes' virtual address spaces to be kept in RAM. So every virtual memory OS is playing a balancing game, trying to keep the most interesting things in RAM. Long experience has shown that using some of the RAM for various sorts of cache is a good optimization. It's certainly better than using some of it for process-private v.a.s. that has never been referenced and may never be referenced.