How my virtual memory am I using?

[thedosbox]

Considering SSD's are generally large enough, and are hardy enough to withstand TiB of writes anyways...

What's the benefit nowadays to disabling the pagefile?

Placebo effect of being able to say they "tweaked" their system for MAXX® performance (despite the lack of evidence)?

 

[Cerb]

Considering SSD's are generally large enough, and are hardy enough to withstand TiB of writes anyways...

What's the benefit nowadays to disabling the pagefile?

Same as with HDDs: being able to get on with whatever you're doing, instead of waiting in slow storage to try to make a memory hog happy. I tried using one with a PF just long enough to have a thrashing incident. Screw that noise.

 

[KernelMode]

That would be fine, except that eliminating the pagefile doesn't eliminate paging to and from disk.

 

[VirtualLarry]

Pagefile is a performance improvement in the common case. It allows evicting stale pages from RAM into the pagefile, allowing you to use that RAM for processes that are currently computing.

Downside, is that it affects application latency in a negative way, first, by causing a slight delay paging things back in when an idle process / window is brought to the foreground, and in a more extreme way, when an application allocates so much pageable memory, that it cannot completely be help in working RAM, causing thrashing.

Now that I think about it, there could exist a no-thrashing registry switch, which would limit total per-process allocations to less than physical RAM limits, even if more pageable memory existed on the system. Might be an interesting tweak for MS to implement.

 

[code65536]

I downsize the page file to a small token amount to support crashdumps not because I care about performance, but because I don't like wasting 16GB of space on a 128GB (or even 256GB) SSD.

But performance? Why the hell would disabling the page file help performance? Windows doesn't page out unless there's memory pressure, and you shouldn't be kneecapping the page file if you are encountering memory pressure. I don't see much in the way of paging activity.

(Now, disabling that idiotic SuperFetch service, OTOH, is well worth it, especially if you have a SSD, but even if you are still using a HDD. Because in the absence of SF, the system seems much more willing to keep old data--like say a large file you copied a while back--resident until it absolutely doesn't need it any more.)

 

[KernelMode]

Now that I think about it, there could exist a no-thrashing registry switch, which would limit total per-process allocations to less than physical RAM limits, even if more pageable memory existed on the system. Might be an interesting tweak for MS to implement.

You probably want to take a look at the Perfmon counter "Virtual bytes" for the "Total" pseudo-instance of the Process object before thinking about this much further. Do this on your system while it is "typically busy".

It is absolutely routine for virtual memory operating systems to run with FAR more virtual memory defined than there is RAM. Performance does not suffer until you have so little RAM that all of the typically accessed v.a.s. can't be kept in RAM at once.

A useful metric to look at is your paging IO rates - pages read and written, page read operations, and page write operations. These are under the Memory object. This will also show any doubters that disabling the pagefile doesn't get rid of paging IO. It doesn't even get rid of page writing to disk.

 

[KernelMode]

(Now, disabling that idiotic SuperFetch service, OTOH, is well worth it, especially if you have a SSD, but even if you are still using a HDD. Because in the absence of SF, the system seems much more willing to keep old data--like say a large file you copied a while back--resident until it absolutely doesn't need it any more.)

SuperFetch has little to do with keeping stuff in RAM, that would be the regular "reactive" Windows file cache, which you can't disable (as a user/admin, that is; programmers can bypass it, that's an option when you open a file).

SuperFetch was really overly aggressive in Vista. One afternoon I installed Adobe Acrobat. 9Full Acrobat, not just Reader.) For several days after I'd notice that my disk LED would start flickering at about that same time each afternoon (it does track usage times and times its prefetching based on when you last asked for the file!). this was on a laptop, and the hit on the hard drive was noticeable. Resource Monitor showed that it was the Superfetch service, reading the installer file! Hm, no, that really wasn't helpful. I thwarted that by renaming the file.

It got a lot more cautious in Win 7, and Windows disables it by default for SSDs. So that's another tweak you don't have to do.

Still, the pages of RAM that SuperFetch uses aren't really "used". It does not increase memory pressure one iota. The pages it uses start on the standby page list (part of the "available" counter in Task Manager), and after SuperFetch uses them they are still on the standby list and are just as available for use by any other process that needs them! It generally uses only the "low priority" portion of the Standby list, meaning stuff that was referenced a long time ago.

 

[Dufus]

you didn't need that little popup dialog with its ambiguous wording (I would've used "virtual" instead of "page" in that dialog for better clarity).

It comes from this function http://msdn.microsoft.com/en-us/library/windows/desktop/aa366589%28v=vs.85%29.aspx which Microsoft call "paging file", I have called it page to differentiate it from people assuming it meant pagefile.sys. Virtual memory is also shown and is as KernelMode describes, 128 TiB.

So that 4GB of physical RAM that's "free" isn't actually 100% free. It's technically "reserved but currently unused".

It's not reserved, it inaccessible unless extra addressing is provided. I've already done the tests assigning memory that is touched and locked from being paged. No pagefile.sys usage even though there is a 4GiB pagefile.sys.

I really don't care anymore, believe what you want.

 

[KernelMode]

It comes from this function http://msdn.microsoft.com/en-us/library/windows/desktop/aa366589(v=vs.85).aspx which Microsoft call "paging file", I have called it page to differentiate it from people assuming it meant pagefile.sys. Virtual memory is also shown and is as KernelMode describes, 128 TiB.

FYI, the "Total Page file" it displays is better called "Commit limit" these days, and "Paging file free" would be that minus the current commit charge. "Commit" comes from the option on VirtualAlloc that creates this stuff. This is a system-wide limit and charge.

"TotalVirtual" is the user-mode virtual address space available to the process. Every process gets another instance of v.a.s.

"AvailVirtual" is how much of that you have left after current private and mapped allocations. Allocations that contribute to commit charge will detract from both "free paging file" and from "free virtual memory", but mapped memory will detract only from "free virtual memory". Reserving memory without committing it (another option on VirtualAlloc) will also change only "free virtual memory".

The "avail physical memory" member does indeed correspond to what task manager shows as "Available". Whoever wrote that sample should not have displayed that number with the word "Free", which is per task manager's terms, a subset of "Available"!

With all this "help" from Microsoft I often feel like trying to bring all this terminology into a coherent picture is like bailing out the Titanic with a sieve. At least they stopped calling "Commit charge" "PF usage" on the XP TM graph... (which led to inevitable questions, like "I disabled my pagefile but the graph still shows that I'm using it!" Argh...)

 

[zir_blazer]

Microsoft nomenclature used to be worse back in the Win 9x days:

http://s.hswstatic.com/gif/ram-vm2.gif

That's where "disable Virtual Memory" comes from.