Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I read: What do the Task Manager memory columns mean?. But I still don't understand what they say.

  • Is Working Set (Mem) exactly a size of process memory on RAM?
  • Is Paged Pool (VirtMem) exactly a size of process memory on swap file?
  • Is total process memory (address space usage) equal to sum of Mem and VirtMem?

Some info available at Wikipedia's Windows Task Manager page.

Seems that Task Manager is right tools to get info about amount of RAM pages owned by process (e.g. discard kernel and driver pages) and how many pages are swapped to disk. But I don't understand which column can show these values.

share|improve this question

migrated from Aug 30 '11 at 16:04

This question came from our site for professional and enthusiast programmers.

Some related… – gavenkoa Aug 30 '11 at 18:38
Some related… – gavenkoa Aug 30 '11 at 18:48
Some related… – gavenkoa Aug 30 '11 at 18:54
Some related… (What is private bytes, virtual bytes, working set?) – gavenkoa Aug 30 '11 at 19:27

It's not clear what you're asking. You ask about "total process memory" as if that were a well-defined term. It's really not. The types of memory measurements that seem natural to people who don't have a deep understanding of memory management basically don't exist on modern systems.

A more useful way to do this is for you to tell us what it is you are trying to figure out. We can tell you how to do that. People tend to say things like "I need to know how much memory a process is using", but that's largely meaningless. It's like asking how much space a person is using. Well, they share the bathrooms, should that count? And they have some stuff stored in the garage, but only because nobody is using it and they could throw that stuff away if anyone needed the space, should that count?

There's really no substitute for studying in some level of detail how modern operating systems manage memory, the distinction between physical and virtual memory, clean versus dirty pages, and so on. That way, you can make sense of the numbers the system actually can provide you.

share|improve this answer
Thanks for clarification. I update question. – gavenkoa Aug 30 '11 at 17:57
"Size of process memory on RAM" is not a well-defined concept. For example, if a program reads a 1GB file and that file is still in RAM, does that count as the size of that process? What if another process is accessing that file too? (Do you think the OS even keeps track of which process read which page of the file?) RAM generally doesn't belong to a process, it all belongs to the OS. – David Schwartz Aug 30 '11 at 18:12
OK. Agree. Size of process memory on RAM is not a well-defined concept. I can not ask more precisely as don't know related terminology... I go reading books about memory management and OS concepts. – gavenkoa Aug 30 '11 at 18:20
Sorry to not give you a quick answer, but if it helps, reading about memory management and getting a deeper understanding will pay off over and over. I promise. – David Schwartz Aug 30 '11 at 18:20

I know this already has an answer accepted but here is perhaps some additional information:

Is Working Set (Mem) exactly a size of process memory on RAM?

No. It is the subset of the process's virtual address space that is "resident", or "present" in the terms of the Intel page table format, meaning that it can be accessed without incurring a page fault. It is a somewhat misleading number for a variety of reasons, chiefly that a) it includes some RAM that is shared with other processes - mostly those that are using some of the same code, like the code from common libraries, and these shared pages are counted in the "working set" of all processes in which they're resident. So if you add up all the "working set" sizes you get a number larger than the true amount used. b) Also, some RAM that was recently lost from the process working set due to page replacement will likely still be on the system's Standby page list, and if so, accessing it will incur a page fault, but not a hard page fault. So that is RAM that contains information from the process that the process may use again - but it isn't counted in the working set.

Is Paged Pool (VirtMem) exactly a size of process memory on swap file?

No. Paged pool is a particular type of kernel-space memory heap. The "Paged Pool" column in the processes display in Task Manager is an indication of how much paged pool has been allocated to support that process's activity.

Is total process memory (address space usage) equal to sum of Mem and VirtMem?

I don't know what you mean by "Mem", but if you mean any count of physical memory allocation, then no. You can'd add physical and virtual memory sizes together and come up with anything sensible. The physical memory used by a process is, rather, a subset of its virtual address space.

Windows has confused this issue through confusing, inconsistent, and changing terminology. In the screen cap you gave, for example, the first four "Memory - " counters are physical (RAM), "Commit size" and "paged pool" are both virtual, and "non-paged pool" which is, like paged pool, a kernel-space heap, but is never paged) is both the virtual and physical size of the allocation.

And a question you didn't ask:

Why is memory management so complicated?

Because it performs a lot better this way than simpler systems have in the past. Sorry about that.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .