New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 724071 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
OOO until 2019-01-24
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

2.9% regression in system_health.memory_mobile at 472365:472398

Project Member Reported by tdres...@chromium.org, May 18 2017

Issue description

See the link to graphs below.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=724071

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


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

android-webview-nexus6
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, May 19 2017

Cc: roc...@chromium.org
Owner: roc...@chromium.org

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

Hi rockot@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 : Ken Rockot
  Commit : f378d95eebc60fd6568c4524abaec2aaa377c7d0
  Date   : Wed May 17 07:59:27 2017
  Subject: Make Service Manager name resolution synchronous

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:malloc:effective_size_avg/load_search/load_search_google
  Change       : 1.18% | 22124093.3333 -> 22384464.0

Revision             Result                  N
chromium@472364      22124093 +- 166883      6       good
chromium@472373      22150939 +- 147634      6       good
chromium@472375      22093186 +- 296372      9       good
chromium@472376      22284065 +- 410170      14      bad       <--
chromium@472377      22369890 +- 306775      9       bad
chromium@472381      22341077 +- 295883      6       bad
chromium@472398      22384464 +- 213884      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.search.google system_health.memory_mobile

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

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


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

Comment 4 by roc...@chromium.org, May 19 2017

Status: WontFix (was: Untriaged)
I don't think this is accurate, so I'm guessing it's maybe just noise? There's nothing about the change that should increase memory usage - in fact it should almost certainly have improved any interesting performance metric as it deletes code, reduces task scheduling overhead, and generally reduces complexity of the system.

https://chromeperf.appspot.com/group_report?rev=472376
Owner: ----
Status: Untriaged (was: WontFix)
If the bisect is wrong, please unassign yourself. A lot of the time there are real regressions that need bisects on different platforms to reproduce. I kicked off a few more.
Project Member

Comment 8 by 42576172...@developer.gserviceaccount.com, May 20 2017

Cc: kbr@chromium.org
Owner: kbr@chromium.org

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

Hi kbr@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 : kbr
  Commit : ebbd3a5c5eee3ec38736e60c53f2ea1bc3faed6c
  Date   : Wed May 17 10:55:21 2017
  Subject: Add command_line to SystemInfo data structure.

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_os:system_memory:native_heap:proportional_resident_size_avg/blank_about/blank_about_blank
  Change       : 1.69% | 16570306.6667 -> 16850370.6667

Revision             Result                   N
chromium@472397      16570307 +- 67497.3      6      good
chromium@472411      16559896 +- 109630       6      good
chromium@472413      16586520 +- 72509.0      6      good
chromium@472414      16571160 +- 70052.4      6      good
chromium@472415      16863000 +- 131798       6      bad       <--
chromium@472418      16869485 +- 113942       6      bad
chromium@472424      16850371 +- 57829.6      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=blank.about.blank system_health.memory_mobile

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

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


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

Comment 9 by 42576172...@developer.gserviceaccount.com, May 20 2017


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

Suspected Commit
  Author : kbr
  Commit : ebbd3a5c5eee3ec38736e60c53f2ea1bc3faed6c
  Date   : Wed May 17 10:55:21 2017
  Subject: Add command_line to SystemInfo data structure.

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_os:system_memory:native_heap:proportional_resident_size_avg/background_social/background_social_facebook
  Change       : 2.15% | 20076312.0 -> 20508781.3333

Revision             Result                   N
chromium@472397      20076312 +- 122889       6      good
chromium@472411      20164717 +- 120377       6      good
chromium@472413      20245443 +- 56243.9      6      good
chromium@472414      20291693 +- 104304       6      good
chromium@472415      20557251 +- 64839.0      6      bad       <--
chromium@472418      20524995 +- 79535.4      6      bad
chromium@472424      20508781 +- 143730       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=background.social.facebook system_health.memory_mobile

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

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


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

Comment 10 by kbr@chromium.org, May 23 2017

Components: Tests>Telemetry
Status: WontFix (was: Untriaged)
I agree looking at the graphs that it seems there was an increase in memory around this time, but my change adds a simple string to a data structure returned via DevTools to Telemetry's harness at the beginning of time, and I can't imagine how that could have led to a persistent increase in the browser's memory usage on these benchmarks, even if Telemetry's calling this API at the beginning of each page.

Closing as WontFix.

Project Member

Comment 11 by bugdroid1@chromium.org, Jun 16 2017

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

commit 958a49a3e9f2f2fe39e5059f73f660e89de8fba3
Author: Kenneth Russell <kbr@chromium.org>
Date: Fri Jun 16 23:11:38 2017

Avoid redundant eglMakeCurrent calls.

The previous fix for initialization of a new virtual context caused
the real context to be released. Avoid this by adding a new entry
point to release only the virtual context so it can be quickly made
current again.

BUG= 718809 ,  724071 

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ieb8c4bfd1db5dfa90168f3a859182efa9c39d0d3
Reviewed-on: https://chromium-review.googlesource.com/534779
Reviewed-by: John Bauman <jbauman@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#480211}
[modify] https://crrev.com/958a49a3e9f2f2fe39e5059f73f660e89de8fba3/gpu/command_buffer/service/gl_context_virtual.cc
[modify] https://crrev.com/958a49a3e9f2f2fe39e5059f73f660e89de8fba3/gpu/command_buffer/service/gl_context_virtual.h
[modify] https://crrev.com/958a49a3e9f2f2fe39e5059f73f660e89de8fba3/gpu/ipc/service/gpu_command_buffer_stub.cc
[modify] https://crrev.com/958a49a3e9f2f2fe39e5059f73f660e89de8fba3/ui/gl/gl_context.cc
[modify] https://crrev.com/958a49a3e9f2f2fe39e5059f73f660e89de8fba3/ui/gl/gl_context.h

Comment 12 by kbr@chromium.org, Jun 17 2017

I realize now I probably shouldn't have referenced this bug in the CL above. I thought that this one had the same culprit CL as  Issue 718809 .

Sign in to add a comment