For Linux platforms add USS and PSS report in get_ext_memory_info()

[GoogleCodeExporter]

Proposal

For Linux platforms add USS and PSS report in get_ext_memory_info()

On what platforms would this be available?

Linux

Please provide any additional information below.

RSS and VMS are not very accurate to track process ram usage, USS and PSS are 
the one to use.

  USS (Unique Set Size) — Indicates the number of pages a process has mapped which are mapped only by that process – which are not mapped by any other process. This is the amount of memory which would be recovered if this process were to be unloaded.

  PSS (Proportional Set Size) — The count of all pages mapped uniquely by the process, plus a fraction of each shared page, said fraction to be proportional to the number of processes which have mapped the page. For example, if a process mapped 1 page that was unmapped by any other process (USS=1), and it mapped a second page which was also mapped by one other process, the PSS value reported would be 1.5. If there were three users of the shared page, the reported PSS would be 1.33.

  RSS (Resident Set Size) — This is currently the most common – but much disparaged – measure of per-process memory under Linux, reported by utilities such as ps and top. It indicates the total count of pages mapped by the specified process, including 100% of all shared pages. For each process shown in a Process/Component Matrix, the sum of the page counts in all of the columns in its row is equal to the RSS value for the process.

- 
http://www.eqware.net/Articles/CapturingProcessMemoryUsageUnderLinux/index.html
- http://www.selenic.com/smem/

Original issue reported on code.google.com by anthony....@gmail.com on 27 Dec 2012 at 12:55

[GoogleCodeExporter]

PSS is already provided by get_memory_maps().
USS looks useful indeed, but it's not clear to me how to retrieve it.

Original comment by g.rodola on 28 Dec 2012 at 3:33

[GoogleCodeExporter]

This might help: http://lwn.net/Articles/236438/ per author's comment URES 
provided by meminfo.py (http://koltsoff.com/pub/meminfo/releases/) is USS.

Original comment by anthony....@gmail.com on 28 Dec 2012 at 3:43

[GoogleCodeExporter]

See also smem: http://selenic.com/repo/smem/file/18af01ef8674/smem

Original comment by anthony....@gmail.com on 28 Dec 2012 at 3:56

[GoogleCodeExporter]

In meminfo it's calculated as (resident - shared).
Since both values are already provided natively I think we better leave USS out 
and just let the user calculate it.

Original comment by g.rodola on 28 Dec 2012 at 4:05

• Changed state: WontFix
• Added labels: OpSys-Linux

[GoogleCodeExporter]

Makes sense.

Original comment by anthony....@gmail.com on 28 Dec 2012 at 4:35

[GoogleCodeExporter]

Note for USS people interested, to match smem USS report, the following should 
be used instead of (resident - shared):

uss = 0
for m in p.get_memory_maps():
    uss += (m.private_dirty + m.private_clean) / 1024

However not sure why smem include private_clean as some reading telling 
private_dirty=uss

Original comment by anthony....@gmail.com on 28 Dec 2012 at 5:08