New issue
Advanced search Search tips

Issue 660152 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 659989
Owner:
Closed: Oct 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

memory.top_10_mobile_stress Failing on several android bots

Project Member Reported by rnep...@chromium.org, Oct 27 2016

Issue description

Project Member

Comment 5 by 42576172...@developer.gserviceaccount.com, Oct 27 2016


===== BISECT JOB RESULTS =====
Status: failed


===== TESTED REVISIONS =====
Revision         Exit Code  Std Dev  N  Good?
chromium@427812  0          N/A      2  good

Bisect job ran on: android_nexus9_perf_bisect
Bug ID: 660152

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_stress
Test Metric: memory:chrome:all_processes:reported_by_chrome:locked_size_avg/memory:chrome:all_processes:reported_by_chrome:locked_size_avg
Relative Change: None
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus9_perf_bisect/builds/2220
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8997614548436602704


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

| 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!
Project Member

Comment 6 by 42576172...@developer.gserviceaccount.com, Oct 27 2016

Cc: lizeb@chromium.org
Owner: lizeb@chromium.org

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

Hi lizeb@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 : android: Don't keep GSA alive if it supports account change broadcasts.
Author  : lizeb
Commit description:
  
Chrome currently connects to a bound service exposed by GSA to get
account change notifications. This elevates GSA's priority for the
system to the foreground level when Chrome is in the foreground,
artificially increasing Chrome's memory footprint. On some phones, the
memory consumption of the GSA process can be above 100MB (PSS), even
though only the account change notifications are required.

Newer versions of GSA send a broadcast intent when the account
changes. This CL listens to the broadcasts, and disonnects from the GSA
service when GSA support the account change broadcast mechanism, freing
the memory for Chrome or other apps on the system.

Note that Chrome still briefly connects to GSA on startup to confirm
that it supports the broadcast. A forthcoming will remove this.

BUG= 614388 

Review-Url: https://codereview.chromium.org/2431223004
Cr-Commit-Position: refs/heads/master@{#427840}
Commit  : e1d19b388fc67f31372a4c2df33e20c0c18dfd97
Date    : Wed Oct 26 22:08:28 2016


===== TESTED REVISIONS =====
Revision         Exit Code  Std Dev  N  Good?
chromium@427820  0          N/A      2  good
chromium@427838  0          N/A      2  good
chromium@427839  0          N/A      2  good
chromium@427840  1          N/A      2  bad    <--
chromium@427841  1          N/A      2  bad
chromium@427843  1          N/A      2  bad
chromium@427847  1          N/A      2  bad
chromium@427856  1          N/A      2  bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 660152

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_stress
Test Metric: memory:chrome:all_processes:reported_by_chrome:v8:effective_size_avg/memory:chrome:all_processes:reported_by_chrome:v8:effective_size_avg
Relative Change: Zero to non-zero
Score: 99.9

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


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

| 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!
Project Member

Comment 7 by 42576172...@developer.gserviceaccount.com, Oct 27 2016


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


===== SUSPECTED CL(s) =====
Subject : android: Don't keep GSA alive if it supports account change broadcasts.
Author  : lizeb
Commit description:
  
Chrome currently connects to a bound service exposed by GSA to get
account change notifications. This elevates GSA's priority for the
system to the foreground level when Chrome is in the foreground,
artificially increasing Chrome's memory footprint. On some phones, the
memory consumption of the GSA process can be above 100MB (PSS), even
though only the account change notifications are required.

Newer versions of GSA send a broadcast intent when the account
changes. This CL listens to the broadcasts, and disonnects from the GSA
service when GSA support the account change broadcast mechanism, freing
the memory for Chrome or other apps on the system.

Note that Chrome still briefly connects to GSA on startup to confirm
that it supports the broadcast. A forthcoming will remove this.

BUG= 614388 

Review-Url: https://codereview.chromium.org/2431223004
Cr-Commit-Position: refs/heads/master@{#427840}
Commit  : e1d19b388fc67f31372a4c2df33e20c0c18dfd97
Date    : Wed Oct 26 22:08:28 2016


===== TESTED REVISIONS =====
Revision         Exit Code  Std Dev  N  Good?
chromium@427802  0          N/A      3  good
chromium@427832  0          N/A      3  good
chromium@427836  0          N/A      3  good
chromium@427838  0          N/A      3  good
chromium@427839  0          N/A      3  good
chromium@427840  1          N/A      3  bad    <--
chromium@427847  1          N/A      3  bad
chromium@427862  1          N/A      3  bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 660152

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_stress
Test Metric: memory:chrome:all_processes:reported_by_chrome:dom_storage:effective_size_avg/memory:chrome:all_processes:reported_by_chrome:dom_storage:effective_size_avg
Relative Change: Zero to non-zero
Score: 99.9

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


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

| 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!
Project Member

Comment 8 by 42576172...@developer.gserviceaccount.com, Oct 27 2016


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


===== SUSPECTED CL(s) =====
Subject : android: Don't keep GSA alive if it supports account change broadcasts.
Author  : lizeb
Commit description:
  
Chrome currently connects to a bound service exposed by GSA to get
account change notifications. This elevates GSA's priority for the
system to the foreground level when Chrome is in the foreground,
artificially increasing Chrome's memory footprint. On some phones, the
memory consumption of the GSA process can be above 100MB (PSS), even
though only the account change notifications are required.

Newer versions of GSA send a broadcast intent when the account
changes. This CL listens to the broadcasts, and disonnects from the GSA
service when GSA support the account change broadcast mechanism, freing
the memory for Chrome or other apps on the system.

Note that Chrome still briefly connects to GSA on startup to confirm
that it supports the broadcast. A forthcoming will remove this.

BUG= 614388 

Review-Url: https://codereview.chromium.org/2431223004
Cr-Commit-Position: refs/heads/master@{#427840}
Commit  : e1d19b388fc67f31372a4c2df33e20c0c18dfd97
Date    : Wed Oct 26 22:08:28 2016


===== TESTED REVISIONS =====
Revision         Exit Code  Std Dev  N  Good?
chromium@427803  0          N/A      3  good
chromium@427831  0          N/A      3  good
chromium@427838  0          N/A      3  good
chromium@427839  0          N/A      3  good
chromium@427840  1          N/A      3  bad    <--
chromium@427842  1          N/A      3  bad
chromium@427845  1          N/A      3  bad
chromium@427859  1          N/A      3  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 660152

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_stress
Test Metric: memory:chrome:all_processes:reported_by_os:private_dirty_size_avg/memory:chrome:all_processes:reported_by_os:private_dirty_size_avg
Relative Change: Zero to non-zero
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_one_perf_bisect/builds/1766
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8997614656547756688


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

| 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!

Comment 9 by lizeb@chromium.org, Oct 28 2016

Status: duplo (was: Untriaged)

Comment 10 by lizeb@chromium.org, Oct 28 2016

Mergedinto: 659989
Status: Duplicate (was: Duplo)
Project Member

Comment 12 by 42576172...@developer.gserviceaccount.com, Apr 11 2017


=== BISECT JOB RESULTS ===
Test failure found but unable to narrow commit range

Build failures prevented the bisect from narrowing the range further.


Bisect Details
  Configuration: android_nexus9_perf_bisect
  Benchmark    : memory.top_10_mobile_stress
  Metric       : memory:chrome:all_processes:reported_by_chrome:locked_size_avg/memory:chrome:all_processes:reported_by_chrome:locked_size_avg

Suspected Commit Range
  -1 commits in range
  Mismatching LKGR/FKBR depots, unable to provide handy url.
  good_revision: chromium@ab7e0537bd2bc17aaadc7da5b3399062ccf1c3e4
  bad_revision : None@None


Revision             Exit Code      N
chromium@427812      0 +- N/A       2      good

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 memory.top_10_mobile_stress

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

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


| 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!

Sign in to add a comment