I watched my laptop on which I am working tonight very carefully.
Two hours ago, there was 170mb of the kernel in VM.
Total free physical mem was around 825mb all the time, and all I have been doing is reading posts here.
Now there is 176mb of the kernel in VM.
Why would the kernel be offloaded to VM without any proper cause like increased ram pressure?
825 free mem seems no reason to start offloading, right?
PS. Thanks for the compliment
Ah, the Task Manager. I have a lot of respect for the way that successive versions of Windows always try to improve the way they express complex and multi-dimensional data in that simple utility. Inevitably, there are compromises.
The "kernel memory" counters do not correspond to the kernel(!). Their full names would be "kernel-mode pool paged bytes" and "kernel-mode pool non-paged bytes". As you may be aware, the distinction between the two is important for driver developers who need to choose between pool pages they can access at elevated IRQL (at or above DPC/dispatch level), the so-called "non-paged pool" because it's guaranteed to always be resident, and the (bigger) "paged pool" areas which are only accessible at "software" IRQLs below 2 because there is no guarantee that those pages will be resident. (IRQL_NOT_LESS_OR_EQUAL is what happens when a driver gets it wrong.)
I just re-read that explanation and it sucks. Another angle...
The "pools" are analogous to a kernel-mode version of heap. Drivers can allocate from either the "paged pool" or "non-paged pool", depending on how they intend to use the memory, but the kernel itself (NTOSKRNL) does not live in either of the memory pools. Hence, the TM's counters which you referred to are more accurately thought of as memory temporarily assigned for drivers' needs.
More importantly, just because something has been trimmed doesn't necessarily mean it's no longer in RAM. The explanation is not trivial. I don't wish to sound patronising, but I don't know anything about your background so I'll talk as if I was presenting to a varied audience...
Once the Mm decides that a resident page in a WS can be safely trimmed, the act of trimming first places the page on the "standby" or "modified" lists, depending on whether the contents of the page have been flagged as altered since the last time they were read from their source (usually the disk). In the simpler case, an unmodified page goes to the standby list where it continues to reside in physical memory, though it is no longer counted in that process WS (TM would show a smaller "mem used"). Should the page be touched again while it is on the standby list, it is "soft-faulted" almost instantaneously back into the WS without incurring HDD access. Modified pages are a bit more complex because they are waiting to be flushed when workload allows.
The "cached" TM counter in Vista and Win 7 is like a catch-all that includes the standby and modified lists, among several other quantities. On machines with lotsa RAM, like the OP's, that "cache" tends to grow to the point where it frequently causes concern among those keen to have their OS "not use up so much of their RAMZ". In fact, the cache contains trimmed pages, so that the effective overall resident process size is composed of the TM-reported WS plus cached portions which are not visible in TM.
Lastly, even if a page is trimmed from the WS and completely purged from every cache level, that's not a problem in situations where the page in question is not being used.
Superfetch and prefetch heuristics obviously add much more complexity on top of all this.
Thanks for a very interesting discussion
======================================
Two hours ago, there was 170mb of the kernel in VM.
As an aside, I'd suggest not using the term "in VM" in that manner. All of this stuff is always "in VM". It's more accurate to refer to pages as "resident" or "paged out".
