>>why does tskmgr indicate that total
memory is real mem + swapfile?
Well, in mine it doesn't add up that way, but I can't make
it add up in any sensible way from the info we're given.
I suspect you're seeing a coincidence.
Here's the description of commit limit from the NT workstation
resource guide:
Commit Limit: Amount of virtual memory, in kilobytes, that can
be committed to all processes without enlarging the paging file.
On my system the paging files at present total 131072K (128mb).
The current commit limit is 185536K, leaving 185536-131072=54464K
unaccounted for.
Physical memory is 64948K, or a discrepancy of page+physical of
64948-54464=10484K. I can't find this number anywhere.
However, I suspect the resource manual is lying. I believe the
185536K figure is the actual max size my page files have been
since the last boot. I have them configured so they can range
from 128mb (as at present) to 200mb. Yesterday I was scanning
images which always runs up my page file sizes near
the max, and, although I didn't check at the time, they were
surely way above the current size.
It is possible that locked-down (non paged) memory is included
in virtual memory, but I can't get that to add up either, and
I don't read the WS Resource manual that way. I think my
guess above is good. It's also testable with a reboot,
which I think I will do when I finish this (I want to
put some registry updates into effect anyhow).
BTW, it is not at all unusual for performance counters to
leave gaping holes in the complete picture of what's going
on (nor for manuals to gloss over that fact, either).
Anyhow, what I said earlier is basically correct,
regardless of how the funny numbers appear. Paged real
memory HAS to be mapped to a page in the swap file in
any practical virtual memory system. Non-paged memory
may or may not be included in the total, but it doesn't
affect the fact that paged memory comes out of the swap
file space, it doesn't add to the swap file space. |
