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

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


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

health-plan-clankium-phone

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8945919696113085648

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: clankium-phone-perf-bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:chrome:all_processes:reported_by_os:gpu_memory:proportional_resident_size_avg/foreground/http_www_amazon_com_gp_aw_s_k_nexus
  Change       : 5.16% | 73436793.9048 -> 77228129.5238

Revision                       Result                   N
android-chrome@1f72ccdb5f      73436794 +- 231697       21      good
android-chrome@1f580f89fc      77228130 +- 7089295      21      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chrome --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http.www.amazon.com.gp.aw.s.k.nexus memory.top_10_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8945919696113085648


For feedback, file a bug with component Speed>Bisection

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8944985228982293040

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: clankium-phone-perf-bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:chrome:all_processes:reported_by_os:gpu_memory:proportional_resident_size_avg/foreground/http_www_amazon_com_gp_aw_s_k_nexus
  Change       : 11.54% | 73358774.8571 -> 81827742.4762

Revision                       Result                   N
android-chrome@7c1146f1ff      73358775 +- 118871       21      good
android-chrome@29caa4aa21      81827742 +- 8350490      21      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chrome --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http.www.amazon.com.gp.aw.s.k.nexus memory.top_10_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8944985228982293040


For feedback, file a bug with component Speed>Bisection

The regression also shows up there at around the same time upstream:https://chromeperf.appspot.com/report?sid=7b44186a12c6df28f4d591ae10fbfac71c39a3c5bf64bdc8b8e6e7407b001364&start_rev=557847&end_rev=562233

Let's see if pinpoint can help.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/161aa3d9240000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/161aa3d9240000

[SPv175+] Force multiple chunks under subsequences by wangxianzhu@chromium.org
https://chromium.googlesource.com/chromium/src/+/b63383e4e3f2b774ce0e6d3bfafb4adc84e48f2b
6.627e+07 → 7.264e+07 (+6.37e+06)

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

After https://chromium.googlesource.com/chromium/src/+/b63383e4e3f2b774ce0e6d3bfafb4adc84e48f2b, the performance pattern just returned to the original pattern before https://chromium.googlesource.com/chromium/src/+/976fc1e074a07d78fc4ccb3ab2a9fbd20fd9ce69

Thanks for looking at this!

Do you have any sense why did r554281 reduce the noise in this metric, and why r559370 reverted to the previous pattern?

Is there something that could be done to keep the noise levels down?

Re #c10: No idea for now. The gpu memory usage is affected by many factors. The change seems about texture memory usage which may be affected by raster invalidation in blink. It's also affected by memory pressure, memory usage of other modules, so it seems hard to analysis the noise.