4

I'm currently writing a report of an application and I want to know its memory usage. Windows 10 has a nice feature that compresses memory that is not in process working sets in order to manage more and to avoid swapping, thus enhancing the overall performance (I think it also exists in linux).

The problem is I don't know if Windows 10's Task Manager reports the total memory usage for each application as if they were uncompressed or it shows the uncompressed part while the rest resides compressed in the system process (which gets really heavy over time by compressing many apps).

Gonzalo
  • 151

2 Answers2

0

Detailed memory measurements can be done with the Windows Performance Toolkit. Here you can trace VAlloc calls to see memory allocations in your tool.

Also RAMMAp can be used to capture a snapshot of the memory usage of your Windows.

But none of the tools can detect how many data are compressed. Maybe Microsoft adds this in the Windows 10 Redstone update.

magicandre1981
  • 99,606
0

The only memory that Windows 10 compresses is in the "System" process. The working set counters you see for other processes do not reflect any compression, nor has any happened. So, you can use the per-process working set counters as you always have.

Memory in a process working set cannot be compressed because anything in the process working set can reference without incurring a page fault. So there would be no opportunity for the memory manager to decompress it. Ordinary code in the process would be referencing (or trying to execute!) compressed memory contents, and that just wouldn't work. Therefore the process working set counters still mean what they've always meant.

As for the "system" process... The compressed memory is a compressed version of pages of RAM that were on the modified page list. Pages are put on the MPL when RAM pressure requires that more RAM be made available. These are pages whose contents were modified while in the process working set, so before they can be made available for other use, their contents must be copied to "backing store" - for process-private pages this is normally the pagefile.

In previous versions of Windows these would have been written to the pagefile and then moved from the MPL to the standby list. From there they could be faulted back into the process that lost them, or else "repurposed" - used as "available" RAM for some other need. The Windows 10 approach is to instead compress their contents and stash the compressed stuff in the private address space of the "system" process.

There is no increase in RAM usage over previous versions. In fact there is a decrease. In the past these pages would have been on the standby list in original - not-compressed - form. Under Windows 10 they're in the system process in compressed form. So they take less room.

The disadvantage is that the process that "lost" these pages cannot simply fault the pages back into its working set (as they can be from the modified or standby page list) because their contents have to be decompressed before being used. The decompression is handled in the usual soft fault resolution path. However the decompression does take much less time than it would take to read the stuff from a pagefile (even on an SSD) in previous versions.

In times of scarce RAM these modified pages can be made available for other use by writing their contents to the pagefile, just as in previous versions. But unlike previous versions, in Windows 10 their contents are already compressed by the time this happens. So they take less time to write and less space in the pagefile. If they later have to be read back in from the pagefile, again, they take less time to read simply because compression means there's less data to read.

Jamie Hanrahan
  • 24,326