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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg7dmfoQoM


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

android-nexus6

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

This looks like a pretty minor regression. Possibly related to MemoryCoordinatorImpl code landing and is expected?

+bashi for FYI.

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

Hi bashi@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Add MemoryCoordinatorImpl
Author  : bashi
Commit description:
  
This CL adds actual implementation of memory coordinator.
The idea is from chrisha@ and a basic strategy is:
* There is only one global state. All processes share the same state.
* The state level calculation is determined by the amount of free
  memory and the median of renderer size (platform-dependent).

BUG= 617492 

Review-Url: https://codereview.chromium.org/2374343002
Cr-Commit-Position: refs/heads/master@{#425786}
Commit  : 529cb14c66359213f1d19b0450ff4d73b25c0e10
Date    : Mon Oct 17 21:55:45 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@425782  1156608  4344.46  8  good
chromium@425784  1159680  6359.64  8  good
chromium@425785  1159680  6359.64  8  good
chromium@425786  1166848  6359.64  8  bad    <--
chromium@425789  1166541  6730.41  5  bad
chromium@425795  1163776  6359.64  8  bad
chromium@425808  1165312  6568.21  8  bad
chromium@425834  1167872  6359.64  8  bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 657068

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile
Test Metric: memory:chrome:all_processes:reported_by_os:system_memory:ashmem:proportional_resident_size_avg/background/after_http_m_intl_taobao_com_group_purchase_html
Relative Change: 0.71%
Score: 95.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus6_perf_bisect/builds/2660
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8998442679986035104


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5235692332908544

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

I don't think my CL regressed memory metrics significantly. Except for instantiating some singleton objects, it does nothing by default (you need to pass --enable-features=MemoryCoordinator explicitly).

I looked at https://chromeperf.appspot.com/group_report?bug_id=657068 and this seems a noise. I think we can mark this as WontFix. Please feel free to re-open this if you have concerns.