Add Tracing for /proc/pic/smaps_rollup
moussaba opened this issue · comments
smaps_rollup provides a more granular and accurate view of a process's memory usage. In particular it provides the Proportional Set Size (Pss) which provides the processes share of the resident memory usage if it uses shared pages with other processes. You will therefore be able to see the Rss vs. Pss in addtion to Swap vs. SwapPss.
We would like to contribute and add tracing capability for the data contained in the smaps_rollup. Any guidance for a starting point would be helpful.
a52q:/proc/10660 # cat smaps_rollup
12c00000-7fd14f2000 ---p 00000000 00:00 0 [rollup]
Rss: 55656 kB
Pss: 7071 kB
Shared_Clean: 31232 kB
Shared_Dirty: 18984 kB
Private_Clean: 240 kB
Private_Dirty: 5200 kB
Referenced: 32716 kB
Anonymous: 23876 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 35232 kB
SwapPss: 1194 kB
Writeback: 0 kB
Locked: 0 kB
In the past we deliberately avoided adding smaps_rollup to our data sources because it's unexpectedly expensive.
The kernel needs to take the map_sem lock for each process (being queried) and needs to traverse all the VMAs to do the accounting, iirc takes 10/20ms per process, 10x than /proc/pid/{statm, status} (which just read a bunch of counters without taking the map_sem lock)
In those 10ms-20ms IIRC pagefaults in the process will be stalled because of the map_sem .
Also anecdotally the union of VmHWM, RssAnon, RssFile, VmSwap that we get from /status has been so far incredibly actionable to tackle hundreds of memory problems in android. We never got in a state where we needed PSS. (what's your use case where /proc/pid/status is not enough out of curiosity?)
The problem of PSS is that is very misleading as a metric. It's mathematically correct (as in, adds up) but has too many surprise factors. You just kill a process, or create a new one, and magically the value for each process goes up/down. This caused many headaches to people who never fully understood how PSS really works.
I've happened to work on memory optimization and memory tracing tools in chromium for ~4 years before starting Perfetto (https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/) and over time concluded that the amount of confusion that PSS creates is larger than the benefit it brings.
Having said this, I am not completely opposed to smaps_rollup in perfetto, but then I would like to see a different toggle (e.g. an explicit opt-in option in process_stats_data_source.cc) to avoid that people use it accidentally.
