All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=922594

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=8ae79025f50ae72f967050c861464650500aa31a0d355a27afdb5de8cd2263c5


Bot(s) for this bug's original alert(s):

Android Nexus5X WebView Perf

memory.top_10_mobile - Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1430f7c0540000

📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/1430f7c0540000

Reland "perfetto: Enable SMB scraping" by eseckler@chromium.org
https://chromium.googlesource.com/chromium/src/+/884929d17a33fadadde7c772e08128e9191c56b6
memory:webview:all_processes:reported_by_os:system_memory:proportional_resident_size: 9.466e+07 → 9.849e+07 (+3.832e+06)

Track when the auto-fetch in progress notification should be shown by harringtond@google.com
https://chromium.googlesource.com/chromium/src/+/0b15d057e7dacd7e14d2ff3b0308c1cc2b706695
memory:webview:all_processes:reported_by_os:system_memory:proportional_resident_size: 9.745e+07 → No values

Revert "Track when the auto-fetch in progress notification should be shown" by timvolodine@chromium.org
https://chromium.googlesource.com/chromium/src/+/dd6d6cf97b6a95c258cb7deb49b6a3ead32ddad1
memory:webview:all_processes:reported_by_os:system_memory:proportional_resident_size: No values → 9.87e+07

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  None

eseckler: the regression is due to your CL:
Reland "perfetto: Enable SMB scraping" by eseckler@chromium.org
https://chromium.googlesource.com/chromium/src/+/884929d17a33fadadde7c772e08128e9191c56b6
memory:webview:all_processes:reported_by_os:system_memory:proportional_resident_size: 9.466e+07 → 9.849e+07 (+3.832e+06)

harringtond, timvolodine: sorry for the noise, the bisect tool is detecting that the test broke/was fixed at your CLs.

Looks like this benchmark produces very little tracing data (not enough to fill up the 4mB shared memory tracing buffer), so scraping the buffer means that the tracing service now actually has to look at the full 4mB rather than just ~1mB of it (to check if there are any in-progress chunks anywhere in the buffer).

Thus, this is an expected regression. I think in the future we should make sure to attribute all the perfetto memory usage to tracing, so that it gets correctly subtracted from most memory metrics. Filed issue 922897 for that. +oysteine FYI.