Windows 7 host process using almost 130mb RAM
- Thread starter UKFX
- Start date
Oh, no, I agree with that. 130MB out of 4GB is not an issue. But the point I was getting at is... how do you actually know that all of that 130MB is actually stored in main memory? What's to say (in the case of DWM.exe) it's not mostly in the GPU memory? What's to say that 130MB isn't being shared with other processes and, therefore, its cost is mitigated by a factor of N processes that are sharing it? And hell even just in general, what's to say that 130MB hasn't been paged out to disk anyway?
It's like when people rabbit on about their web browser memory usage. How many of them are even aware of the concept that memory regions can be shared between processes? Web browser tabs, hell even just multiple instances of the full browser... these things all benefit hugely from shared memory regions. And it all happens deep inside the NT kernel. The software itself doesn't know (nor care) about it.
It's like when people rabbit on about their web browser memory usage. How many of them are even aware of the concept that memory regions can be shared between processes? Web browser tabs, hell even just multiple instances of the full browser... these things all benefit hugely from shared memory regions. And it all happens deep inside the NT kernel. The software itself doesn't know (nor care) about it.
RAM usage should never be a problem (unless you have <100MB left). Windows is using that RAM to accelerate various tasks through caching. You paid good money for that RAM, you should expect Windows to make as much use of it as possible.
CPU usage is what you should be watching at idle.
CPU usage is what you should be watching at idle.
This is why I love Windows. It is so very clever, but many people just don't appreciate it
Virtual Memory
Private Bytes: Bytes which are allocated to the process privately (non-shareable)
Peak Private Bytes: The highest the above value as been for the process.
Virtual Size: The total amount of virtual memory allocated for the process. Note: Virtual memory is not an "overflow carpark". It is always-on. It's a bit like valet parking. You hand over your keys, the valet then goes and parks your car in a free space in one of many possible car parks. When you come back he executes a "page fault" and goes and gets your car from where he stored it. The valet in this analogy is the virtual memory manager.
Page Faults: The number of times the process has requested a page of memory (every page is 4KB) and the memory manager realise he had paged it out to disk. So the process had to wait whilst it was brought back in from disk to the main memory. They aren't really "faults". They are standard and normal operation. The terminology of "fault" came from the manufacturers of CPUs (like Intel) because for a CPU the inability to access a page of memory in the virtual memory table is considered quite a serious fault and hence it fires off a page fault interrupt to the kernel.
Page Fault Delta: The number of the above which occured with the update cycle of Process Explorer.
Physical Memory
Memory Priority: A new concept in NT 6.0 which assigns each process a memory priority. This isn't used all that much yet. But things like Superfetch do use it. The memory manager will use this to prioritise requests for memory. A low priority process could find itself being rejected a memory allocation if pressure is sufficient.
Working Set: The amount of bytes in the virtual memory allocation for the process which are currently paged-in (i.e. in main memory). The working set is analogous to your desk. You have the papers and books that you are working with at that point in time. Unless you're very messy, once you're finished you tend to put these items back on the shelf or in filing cabinets. The latter are analogous to the page file.
WS Private: The amount of bytes in the current working set which are private (non-shareable) to the process.
WS Shareable: The amount of bytes in the working set which can be shared with other processes. This includes things like memory mapped files, code regions (.DLL, .EXE files) and.. in the case of DWM.exe like the screenshot: DirectX textures. So that Explorer can show those nice whizzy effects on the taskbar where it previews each window - and for other things like Flip3D.
WS Shared: As above but which are actively being shared with at least one other process.
Peak Working Set: The highest the working set has been for the process.
Note that Process Explorer currently has no way to correctly display how much GPU memory a process is using. It provides no metrics for it at all. So we have no way of knowing. However, you can get a good idea just by loading a new window of any program (like your web browser) and maximising it. You will see that DWM.exe's "WS Shareable" figure will jump. For me, it jumped by about 10MB. But I'm running 1920x1280 resolution. So let's work that out... 1920 x 1280 x 4 (32-bit colour depth = 4 bytes) = 9,830,400 bytes / 1024 / 1024 = 9.375 MB. Yep, sounds about right.
Sooner or later Mark Russinovich will improve his Process Explorer tool to display a "Main Memory Working Set" (along with the breakdown of Private, Shareable, Shared) and a "GPU Working Set" (again, with a breakdown).
This is why I love Windows. It is so very clever, but many people just don't appreciate it
It's difficult to appreciate a dvd smarter than myself
