the confusing term page file

[matsp]

Thanks matsp,


I agree with all of your analysis. Great!

Just two more comments,

1.



Suppose the case of copy on write and request for zero, I think even if the memory is marked as comitted during API call to VirtualAlloc, since the memory is not actually used, such type of memory is not counted as a part of committed charge. right?

Yes, only pages that are ACTUALLY being used are counted, not uncommitted pages, such as those that need to be filled with zero or copied if written.

2.

PF is the same as committed charge in task manager. Agree?

I think, when it comes to Task Manager, this concept holds.

3.

PF contains totally currently used memory, including the consumed system swap page file and the consumed real physical memory. Right?

Most likely, yes.

4.



1) You can see from matsp's analysis, there is still something unclear.
2) With the growth of our experience, we will have different and deeper view of the same question. I am sure you have this experience before.


regards,
George

--
Mats

[George2]

Thanks Mats,


It is great that you agree with my point 1, 2 and 3. Let us come back to the original question, which I do not agree.

Let me quote the word from the Windows Internals book,

--------------------
Thus, the Process: Page File Bytes performance counter is actually the total process private committed memory, of which none, some or all may be in the paging file (In fact, it's the same as the Process: Private Bytes performance counter).
--------------------

You can open perfmon, and monitor Page File Bytes and Private Bytes for _Total, you can obviously see they are different. :-)

Any comments?

Yes, only pages that are ACTUALLY being used are counted, not uncommitted pages, such as those that need to be filled with zero or copied if written.

I think, when it comes to Task Manager, this concept holds.

Most likely, yes.


--
Mats

regards,
George

[matsp]

They aren't identical, meaning that the measurement is probably not done at exactly the same point [or on exactly the same data], but they are pretty darn close - if you are worried about the last tens of kilobytes in a machine using 100+ MB, then I think you have too much time on your hands.

--
Mats

[George2]

Thanks Mats,


1. so you agree they are not the same thing?

2. On my machine, they are quiet different, paging file total 400, private bytes total 3600.

They aren't identical, meaning that the measurement is probably not done at exactly the same point [or on exactly the same data], but they are pretty darn close - if you are worried about the last tens of kilobytes in a machine using 100+ MB, then I think you have too much time on your hands.

--
Mats

regards,
George

[matsp]

What does your application do? Is it, perhaps, using Mapped Views of Files? I expect that to throw the bytes off by a fair bit, since mapped view isn't part of "private data" in the same sense.

--
Mats

[George2]

Yes, Mats!


1.

I am programming with memory map files. But in this case, I do not run any addtional applications on my Windows Server 2003, and simply watch what system performance counter look like during idle.

I think your point is private bytes does not include the shared memory map file, so the figures are different, right?

2.

But the confusion is, Page File Bytes counter from perfmon and PF from task manager are not the same thing -- too confusing.

I quote some information here and let me know whether you agree or not?

from perfmon help

--------------------
Page File Bytes is the current amount of virtual memory, in bytes, that this process has reserved for use in the paging file(s). Paging files are used to store pages of memory used by the process that are not contained in other files. Paging files are shared by all processes, and the lack of space in paging files can prevent other processes from allocating memory. If there is no paging file, this counter reflects the current amount of virtual memory that the process has reserved for use in physical memory.
--------------------

Windows Internals Version 4,

(Page 446, Table 7-15)

--------------------
Number of bytes of virtual (not reserved) memory that has been committed. This number doesn't necessarily represent page file usage because it includes private committed bytes in physical memory that have never been paged out. Rather, it represents the amount of page file space that would be used if the process was completely made nonresident.
--------------------

(Page 447)

--------------------
Note the Mem Usage Bar (called PF Usage in Windows XP and Windows Server 2003) is actually the system commit total. This number represents potential page file usage, not actual page file usage.
--------------------

What does your application do? Is it, perhaps, using Mapped Views of Files? I expect that to throw the bytes off by a fair bit, since mapped view isn't part of "private data" in the same sense.

--
Mats

regards,
George

[matsp]

Well, on my XP system, they are essentially equal - a few tenths of percent difference, but not a factor of ten out.

I don't know what is happening in Server 2003 to make it different - the kernel is essentially the same with W2K3 and XP.

--
Mats