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

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


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

android-nexus5X

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

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

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:chrome:all_processes:reported_by_chrome:java_heap:effective_size_avg/browse_news/browse_news_washingtonpost

Revision             Result                  N
chromium@472068      64661175 +- 379312      21      good
chromium@472153      64657099 +- 385849      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-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=browse.news.washingtonpost system_health.memory_mobile

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8978867202922982208

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5007513029705728


| 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 Speed>Bisection.  Thank you!

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

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

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:chrome:all_processes:reported_by_chrome:java_heap:effective_size_avg/browse_news/browse_news_washingtonpost

Revision             Result                  N
chromium@472068      64632764 +- 233078      21      good
chromium@472153      64688246 +- 491055      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-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=browse.news.washingtonpost system_health.memory_mobile

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8978861581250570736

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5007513029705728


| 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 Speed>Bisection.  Thank you!

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

=== Auto-CCing suspected CL author ke.he@intel.com ===

Hi ke.he@intel.com, 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 : ke.he
  Commit : 1d1971a0a142a71f3cb66aa36198fbb9671c9910
  Date   : Tue May 16 03:14:25 2017
  Subject: Remove base::NonThreadSafe from //device/generic_sensor/

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:chrome:all_processes:reported_by_chrome:java_heap:effective_size_avg/browse_news/browse_news_washingtonpost
  Change       : 0.08% | 64600792.7143 -> 64649830.8571

Revision             Result                   N
chromium@472000      64600793 +- 139896       14      good
chromium@472001      64657470 +- 27958.1      6       bad       <--
chromium@472002      64674562 +- 80893.6      6       bad
chromium@472003      64682226 +- 79078.5      6       bad
chromium@472006      64774377 +- 488436       6       bad
chromium@472011      64688995 +- 240737       6       bad
chromium@472022      64678759 +- 181882       6       bad
chromium@472043      64676850 +- 201298       9       bad
chromium@472085      64702302 +- 155581       6       bad
chromium@472170      64649831 +- 212979       14      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 --story-filter=browse.news.washingtonpost system_health.memory_mobile

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8977000785581447248

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=4830264687067136


| 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 Speed>Bisection.  Thank you!

Hi, Reilly, my CL here is just to replace the NonThreadSafe into ThreadChecker.
I think it shouldn't break the memory benchmark test? WDYT?

And, sorry I knows little about the system health test here.
In my Ubuntu16.04 I built out the ChromePublic.apk. and install it on my android phone(4.4.4, XIAOMI, not Nexus), and keep the USB cable connected to the phone.

Then Either I run:
tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=browse.news.washingtonpost system_health.memory_mobile

Or run below commands like the doc said:
tools/perf/run_benchmark run system_health.memory_mobile \
    --browser android-chromium --story-filter browse.news.washingtonpost

It turns out both above commands failed with "Cannot find browser of type android-chromium." Any comments?

Thanks very much.

This benchmark is really noisy and it looks like it recovered before alerting again for another patch. Your change should have had a net zero to positive effect on memory usage but the fact is that since the Generic Sensors service isn't even initialized by default since it is behind a flag I don't think it's to blame here.

Reilly, Thanks!

Hi, Henry, I guess it might be other CL that broke the benchmark test?
Thanks!

Wontfixing due to comments 8-19