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

=== BISECT JOB RESULTS ===
NO Test failure found

Bisect Details
  Configuration: android_one_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:chrome:all_processes:dump_count:background_avg/memory:chrome:all_processes:dump_count:background_avg

Revision             Exit Code      N
chromium@503116      1 +- N/A       5      good
chromium@503197      1 +- N/A       5      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-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests 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/8965538300657826096


For feedback, file a bug with component Speed>Bisection

Spent a little time looking at this today. The issue is that the bot is consistently timing out, so results are never saved or uploaded.

Will try to come back at this, hopefully tomorrow, and dig a bit further.

Maria: I think just keeping system_health.memory_mobile passing on low end devices would get us quite far with memory benchmarking. Should we have your team be the point of triage for system_health.memory_mobile's breakage on Android one?

 Issue 795048  has been merged into this issue.

This is an ongoing issue, and seems to lead to cause system_health.memory_mobile to fail 10-20% of the time on Android One. 

I'm the current bot health sheriff and responsible for keeping the bots green. I'm assuming that we don't just want to disable system_health.memory_mobile on this platform, so I'm going to bump up the timeout from 3h to 4h given that successful runs of this benchmark regularly take around 2h50m.

Juan, Maria, can you work together to come up with a long-term plan for how we should address this?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a79793994cb8f772fd9f6039a4c45535d53091d6

commit a79793994cb8f772fd9f6039a4c45535d53091d6
Author: Charlie Andrews <charliea@chromium.org>
Date: Thu Dec 14 19:50:43 2017

Increase the system_health.memory_mobile timeout from 3h to 4h

The benchmark regularly takes around 2h50m-3h on Android One, and has
been regularly timing out for the past several months on the waterfall.

NOTRY=true
TBR=nednguyen@google.com

Bug:  775242 
Change-Id: I2945eef4c12bcf9540c93760c33f54df66dffc9a
Reviewed-on: https://chromium-review.googlesource.com/827605
Commit-Queue: Charlie Andrews <charliea@chromium.org>
Reviewed-by: Charlie Andrews <charliea@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524150}
[modify] https://crrev.com/a79793994cb8f772fd9f6039a4c45535d53091d6/testing/buildbot/chromium.perf.json
[modify] https://crrev.com/a79793994cb8f772fd9f6039a4c45535d53091d6/tools/perf/core/perf_data_generator.py

Increasing the timeout did help (thanks Charlie!), and the benchmark has been running a lot better after fixing  issue 785446 . Not sure if there is much else left to do here?

I'll check again in a few days, and close if the benchmark remains relatively happy.

Great! Thanks for fixing  issue 785446  Juan - that was a big one.

The NextAction date has arrived: 2017-12-21