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

Issue 654691 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

33x more skia memory on ChromiumPerf/android-one/v8.browsing_mobile / memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg / browse_news / browse_news_flipboard

Project Member Reported by hpayer@chromium.org, Oct 11 2016

Issue description

Comment 2 by hpayer@chromium.org, Oct 11 2016

Cc: primiano@chromium.org u...@chromium.org
Also visible on system health: https://chromeperf.appspot.com/report?sid=2480fb65c9baed565249c609770f1cb60551b6bd3f2d2a38ff0f307098b4bc1f&start_rev=405220&end_rev=424328

We have to turn on alerts for these metrics. Will file a bug for that.

Comment 3 by hpayer@chromium.org, Oct 11 2016

Summary: 33x more skia memory on ChromiumPerf/android-one/v8.browsing_mobile / memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg / browse_news / browse_news_flipboard (was: 20x more skia memory on ChromiumPerf/android-one/v8.browsing_mobile / memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg / browse_news / browse_news_flipboard)

Comment 4 by hpayer@chromium.org, Oct 11 2016

Cc: hpayer@chromium.org
Owner: caryclark@chromium.org
Status: Assigned (was: Untriaged)
I only see one skia roll in the suspected cl range (bisect started in the meantime). Assigning to caryclark in the meantime. Could you please have a look and/or triage on the skia side.


Comment 5 by hpayer@chromium.org, Oct 11 2016

Cc: hablich@chromium.org
Components: Internals>Skia
Labels: -Pri-2 M-55 ReleaseBlock-Stable Performance-Memory Pri-1
This should be fixed in 55 before it hits Stable.
Project Member

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


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


===== TESTED REVISIONS =====
Revision         Mean      Std Dev  N  Good?
chromium@423899  4477564   757303   5  good
chromium@423990  4211311   929485   4  good
chromium@424036  3880321   359031   5  good
chromium@424080  60981767  5187339  5  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 654691

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests v8.browsing_mobile
Test Metric: memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg/browse_news/browse_news_flipboard
Relative Change: 1337.46%
Score: 0

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


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

| 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!
Owner: caryclark@google.com
Owner: hpayer@chromium.org
Could you identify the Skia roll mentioned in #4 that you suspect? That would be a great help.
Cc: djsollen@chromium.org
I've found 2 Skia Rolls (total of 22 commits) that seem to fall in the range, but I don't know how to narrow it down from there.  I also don't know enough about these dashboards, but I noticed that on the exact same perf PointID the amount of memory reported for  memory:chrome:renderer_processes:reported_by_chrome:effective_size_avg also shot way up.  Does that test include the skia numbers?

RANGE:
https://chromium.googlesource.com/chromium/src/+log/f9c8562e55b669915faf87d8d7eda32ae62bf661..020999d2033e17c3a14f779a0ae845530a71898f

SKIA COMMITS:
https://chromium.googlesource.com/chromium/src/+/c243409f8f9f7cfcae4264c1b1884cbef4feef3c
https://chromium.googlesource.com/chromium/src/+/9bb2951f850ffc3006054e4799c01740d52e9192
Yes, that should include the skia numbers. It seems to reproduce on the bots, could you try reproducing it locally?

primiano, do you have any advice? Why does the bisect not work?
So, I just found a correlation in the system_health benchmark. Same story (flipboard), skia memory going up:
https://chromeperf.appspot.com/report?sid=fe028e29aa4965e1f1f36a53a16cdc5509e7e349b7b9051c756d0f517f7d0092&start_rev=423356&end_rev=424959

Fun fact: the system health has a narrower CL range, and there is no skia roll there.
Kicking off a bisect on that benchmark, let's see what happens:
https://chromeperf.appspot.com/buildbucket_job_status/8998196088468710672
Project Member

Comment 16 by 42576172...@developer.gserviceaccount.com, Oct 21 2016

Bisect failed: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_one_perf_bisect/builds/1749
Failure reason: the build has failed due to infrastructure failure.

Looks like the provision_device step failed. Very likely the device attached died.
[Bulk edit]

URGENT - PTAL ASAP.

This issue is marked as a stable release blocker for Android M55.  We will be cutting our stable candidate from branch 2883 on Tuesday, 11/29, so *all* blockers must be fixed on trunk by Monday, 11/28 to allow time to merge back to the branch.  Please review this issue ASAP.

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.

Unsure if the issue should block the release, or think that the issue should block the release but you know you won't be able to fix it in time?  Please CC me to the bug so that we can discuss options.

Thanks!
Project Member

Comment 21 by 42576172...@developer.gserviceaccount.com, Nov 22 2016

Cc: ssid@chromium.org
Owner: ssid@chromium.org

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

Hi ssid@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 : [tracing] Support BACKGROUND mode in MemoryCache dump provider
Author  : ssid
Commit description:
  
This CL adds support for BACKGROUND mode in MemoryCache dump provider,
where it just adds the total sizes of resources (given by encodedSize
of each resource).
This CL also fixes the image resources reporting which had a shared
buffer that was not reported in the ImageResource subclass.
It also fixes the SharedBuffer::onMemoryDump to dump when both shared
buffer and segments are used together.

BUG= 629925 

Review-Url: https://codereview.chromium.org/2337733002
Cr-Commit-Position: refs/heads/master@{#418957}
Commit  : 203b334b85d015fb651010ba89e6c6f31bae2b2e
Date    : Thu Sep 15 20:42:24 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@418923  3885416  275473   8  good
chromium@418944  3930955  310220   8  good
chromium@418955  3911757  156679   8  good
chromium@418956  3904505  216384   8  good
chromium@418957  196972   45582.5  5  bad    <--
chromium@418958  201563   16108.9  4  bad
chromium@418960  214601   80231.3  5  bad
chromium@418965  209739   10587.4  5  bad
chromium@419007  167781   31578.6  5  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 654691

Test Command: 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.flipboard v8.browsing_mobile
Test Metric: memory:chrome:renderer_processes:reported_by_chrome:partition_alloc:effective_size_avg/browse_news/browse_news_flipboard
Relative Change: 95.68%

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


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

| 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!
Owner: hjd@chromium.org
ssid, ignore this. My bad bisecting on the wrong chart. This one was fixed.
The real problem is still here: 
https://chromeperf.appspot.com/report?sid=2480fb65c9baed565249c609770f1cb60551b6bd3f2d2a38ff0f307098b4bc1f&start_rev=423719&end_rev=424234

hjd@: I kicked another bisect here. If it doesn't come back, can we use your offline script do dig into this? It seems quite sharp as a regression
Project Member

Comment 25 by 42576172...@developer.gserviceaccount.com, Nov 22 2016

Cc: danakj@chromium.org
Owner: danakj@chromium.org

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

Hi danakj@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 : Move memory observer off OutputSurface/CompositorFrameSink
Author  : danakj
Commit description:
  
Instead make ContextProviderCommandBuffer be a memory observer, and
avoid interfaces inheriting other interfaces.

R=ericrk@chromium.org
BUG= 606056 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2408513002
Cr-Commit-Position: refs/heads/master@{#424039}
Commit  : 2871a8c3516e495b9e9acedfe9c0fd43dc9b7b06
Date    : Sat Oct 08 01:55:53 2016


===== TESTED REVISIONS =====
Revision         Mean       Std Dev   N  Good?
chromium@424007  1995361    3493529   7  good
chromium@424031  2758587    5596194   7  good
chromium@424037  2253474    3131109   8  good
chromium@424038  2414341    4218435   8  good
chromium@424039  95244502   23527251  5  bad    <--
chromium@424040  99880746   16366338  5  bad
chromium@424043  100269118  6211157   5  bad
chromium@424055  93270032   18679063  5  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 654691

Test Command: 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.flipboard system_health.memory_mobile
Test Metric: memory:chrome:all_processes:reported_by_chrome:skia:effective_size_avg/browse_news/browse_news_flipboard
Relative Change: 4574.34%

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


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

| 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 26 by 42576172...@developer.gserviceaccount.com, Nov 22 2016


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


===== SUSPECTED CL(s) =====
Subject : Move memory observer off OutputSurface/CompositorFrameSink
Author  : danakj
Commit description:
  
Instead make ContextProviderCommandBuffer be a memory observer, and
avoid interfaces inheriting other interfaces.

R=ericrk@chromium.org
BUG= 606056 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2408513002
Cr-Commit-Position: refs/heads/master@{#424039}
Commit  : 2871a8c3516e495b9e9acedfe9c0fd43dc9b7b06
Date    : Sat Oct 08 01:55:53 2016


===== TESTED REVISIONS =====
Revision         Mean       Std Dev   N  Good?
chromium@424007  1234816    2397390   8  good
chromium@424031  2907302    5389567   8  good
chromium@424037  1808260    4678849   7  good
chromium@424038  2229241    3530703   8  good
chromium@424039  102365708  4603673   5  bad    <--
chromium@424040  96918687   16069926  5  bad
chromium@424043  99803558   8152091   5  bad
chromium@424055  101673300  6371762   5  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 654691

Test Command: 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.flipboard system_health.memory_mobile
Test Metric: memory:chrome:all_processes:reported_by_chrome:skia:effective_size_avg/browse_news/browse_news_flipboard
Relative Change: 8133.89%

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


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

| 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 27 by ssid@chromium.org, Nov 22 2016

I think this change is expected from the CL.
The memory that was shown under "gpu" category is now displayed under skia.
https://chromeperf.appspot.com/report?sid=57cd4e4423f0cc140b2872efc0322a3ed63782ca5c0276f812bd46a50c674b1a
ericrk/danakj that seems definitely the culprit: is the shift in the metric intended?
Status: WontFix (was: Assigned)
Yeah, this moved memory from the "gpu" in the browser process (which was essentially unaccounted for memory) to "skia" in the renderer process, because we started reporting memory from more contexts - in this case the context used by canvas.
Project Member

Comment 30 by 42576172...@developer.gserviceaccount.com, Nov 23 2016


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


===== TESTED REVISIONS =====
Revision         Mean      Std Dev   N  Good?
chromium@423899  4570578   1196955   6  good
chromium@423990  4190988   1213254   5  good
chromium@424035  4522085   740417    9  good
chromium@424036  4716681   0.0       1  unknown
chromium@424037  4523000   456745    2  unknown
chromium@424038  N/A       N/A       0  unknown
chromium@424039  51552262  0.0       1  unknown
chromium@424040  15006486  16407693  2  unknown
chromium@424041  57997630  3762862   3  unknown
chromium@424042  50712514  8590539   3  unknown
chromium@424043  56343794  4906945   4  bad
chromium@424047  50067233  40576017  5  bad
chromium@424058  60364349  11946223  4  bad
chromium@424080  60896339  7512494   6  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 654691

Test Command: 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.flipboard v8.browsing_mobile
Test Metric: memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg/browse_news/browse_news_flipboard
Relative Change: 1232.36%

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


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

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

Sign in to add a comment