Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Pastimes : Dream Machine ( Build your own PC ) -- Ignore unavailable to you. Want to Upgrade?

To: Dave Hanson who wrote (3557)	11/15/1998 10:55:00 PM
From: Sean W. Smith	Read Replies (1) \| Respond to of 14778

Again, very helpful. I'm sure others agree. Question: given that all real mem is mapped to the pagefile, why does tskmgr indicate that total memory is real mem + swapfile? Just a (misleading) convention? If would be more useful to list available memory as the larger of the pagefile or the physical ram, since that's all it will hold anyway. Obviously I was misinformed about the allocation of data to the swapfile. Thanks for clearing that up! Apologies to Mrs. Spots too <g>. On a similar note. Anyone know how to monitor page faults that actually cause a flush and reload of a page from disk rather than the total # of faults which may not necessiarly involve a swap? Sean

To: Dave Hanson who wrote (3557)	11/16/1998 11:33:00 AM
From: Spots	Read Replies (2) \| Respond to of 14778

>>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.