Audit memory reporting mechanisms on macOS [ for waterfall memory tests] |
||
Issue descriptionhttps://chromeperf.appspot.com/report?sid=a1cd291ab19b905530fa1b864c338cd448311848f7c0b5cdcfb638b3c22e5ac1&start_rev=420426&end_rev=446358 These graphs show "reported_by_os:resident_size_avg", and the graphs look bad, but also suspiciously linear. We should audit all the memory-reporting mechanisms to make sure they're sane. e.g. what is "reported_by_os:resident_size_avg" actually measuring?
,
Jan 26 2017
Interesting datapoint. For a brand new Canary browser process on OSX with just about:blank opened:
memory-infra in chrome://Tracing reports
total resident: 203 MB
malloc: 65 MB effective
83 MB incl the tracing overhead
124 MB virtual size
vmmap of the same process shows:
All malloc zones:
123 MB virtual size
75 MB allocated
so the numbers for malloc roughly match (the divergencies in the accounting of tracing overheads are WAI and are going to be dealt with by bit.ly/tracingv2)
Activity monitor, for the same process, shows:
Memory: 105 MB
Real Mem: 203 MB
Private Mem: 124 MB
now, the question I have are:
1) What do these numbers reported by activity monitor mean?
It seems that whatever we report in memory-infra as "total resident" match activity monitor's notion of "Real mem".
2) what are those 203 MB? What is there other than malloc (Which itself seems to be reported fine)?
among the various things, vmmap reports 36.6M of shared_memory. That could be one piece.
shared_memory is a missing piece but thankfully there is active work being done here (https://codereview.chromium.org/2535213002/)
,
Jan 26 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by erikc...@chromium.org
, Jan 26 2017