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

[giampaolo]

From anthony....@gmail.com on December 27, 2012 13:55:40

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: http://code.google.com/p/psutil/issues/detail?id=347

[giampaolo]

From g.rodola on December 27, 2012 19:33:21

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

[giampaolo]

From anthony....@gmail.com on December 27, 2012 19:43:58

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.

[giampaolo]

From anthony....@gmail.com on December 27, 2012 19:56:34

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

[giampaolo]

From g.rodola on December 27, 2012 20:05:37

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.

Status: WontFix
Labels: OpSys-Linux

[giampaolo]

From anthony....@gmail.com on December 27, 2012 20:35:17

Makes sense.

[giampaolo]

From anthony....@gmail.com on December 27, 2012 21:08:49

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