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

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


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

android-webview-nexus6

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

=== Auto-CCing suspected CL author vmpstr@chromium.org ===

Hi vmpstr@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Vladimir Levin
  Commit : 9167e1c4eb3a1b6d094399e35efe427185303428
  Date   : Wed Oct 18 21:28:24 2017
  Subject: cc: Plumb decoding mode state to checker image tracker.

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:cc:effective_size_avg/load_media/load_media_dailymotion
  Change       : 22.68% | 36571544.0 -> 44865996.0

Revision             Result               N
chromium@509828      36571544 +- 0.0      6      good
chromium@509863      36571544 +- 0.0      6      good
chromium@509872      36571544 +- 0.0      6      good
chromium@509876      36571544 +- 0.0      6      good
chromium@509878      36571544 +- 0.0      6      good
chromium@509879      44865996 +- 0.0      6      bad       <--
chromium@509880      44865996 +- 0.0      6      bad
chromium@509897      44865996 +- 0.0      6      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-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=load.media.dailymotion system_health.memory_mobile

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

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


For feedback, file a bug with component Speed>Bisection

Vlad: the bisect is showing an 8MiB regression at your CL. That's a lot! Can you please take a look? You can access the memory dumps in the traces from the perf dashbaord here:

Before your CL: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/load_media_dailymotion_2017-10-18_20-11-26_83130.html
After your CL: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/load_media_dailymotion_2017-10-18_23-29-02_37034.html

Hmm it's possible that we should only store this state if the decoding mode isn't the default. Khushal, what do you think?

The regression is in GPU memory from a single image of size 8M. If you look at memory reported under cc:image_memory:cache:gpu, you can see the additional entry. The patch above changed whether we would use async decoding on an image in cc or not. My best guess is that earlier there was something that was using async decoding so we skipped uploading it, but now it uses sync decoding so the upload isn't skipped. It should be easy to verify this with a cc trace of this test case.