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

Issue 687591 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jan 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

13.6% regression in system_health.memory_mobile at 447197:447209

Project Member Reported by pmeenan@chromium.org, Feb 1 2017

Issue description

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

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


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

android-nexus5X
Cc: eholk@chromium.org
Owner: eholk@chromium.org

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

Hi eholk@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 : eholk
  Commit : 91f8a063cc508f51a18ad9c69faf032552c9d012
  Date   : Tue Jan 31 02:25:57 2017
  Subject: [wasm] Move protected instruction info to RelocInfo

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:chrome:all_processes:reported_by_chrome:v8:effective_size_avg/background_search/background_search_google
  Change       : 13.93% | 16845980.5714 -> 19173630.2222

Revision                           Result                   N
chromium@447196                    16845981 +- 1144555      14      good
chromium@447197                    17166486 +- 2817852      14      good
chromium@447197,v8@bc57081795      17325942 +- 2186934      9       good
chromium@447197,v8@91f8a063cc      19233040 +- 4690832      14      bad       <--
chromium@447198                    19415369 +- 4259164      14      bad
chromium@447199                    19463472 +- 3008662      6       bad
chromium@447203                    19134625 +- 5979551      14      bad
chromium@447209                    19173630 +- 3850390      9       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=background.search.google system_health.memory_mobile

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

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


| 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!
Labels: Performance-Memory
Status: Assigned (was: Untriaged)
Explictly assigning. A CL you landed tripped one of the speed metrics we measure in the lab. If this is the first time this has happened to one of your CLs, or if it's been a while, please read: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/addressing_performance_regressions.md

We're looking for one of the following:
1. Justification via explanation
2. Plan to revert or fix
3. Angry rage throwing of equipment at my head

Just be aware that I'm trained in trumpet playing and First Aid and am not afraid to use it.

Note: This was a bulk edit message and not very personal.
eholk: ping? This is a 2mib regression, that's pretty severe.

Comment 7 by eholk@chromium.org, Sep 15 2017

I'll look into this some more today. Sorry for the delay!

Comment 8 by eholk@chromium.org, Sep 15 2017

I'm not sure https://crrev.com/2651833003 is actually the culprit here. It is almost entirely deleting code (for example, removing a field from the Code object). The behavioral changes are only when compiling WebAssembly code, and then only when trap handlers are enabled. Trap handlers are only enabled on Linux x64, and I doubt this test in February was running much if any WebAssembly code.

Comment 9 by eholk@chromium.org, Sep 15 2017

Would it be possible to re-bisect this?

Also, what does the +- column mean? The bisect results are showing +- 4.7 MiB, which is pretty big relative to a 2 MiB regression.

Comment 10 by eholk@chromium.org, Sep 15 2017

Cc: benhenry@chromium.org bradnelson@chromium.org sullivan@chromium.org
Thanks for taking a look! I kicked off a new bisect. The first one shows a pretty clear jump at your CL, but it is possible the metric can be bimodal and every once in a while jump like that at a random CL.
Project Member

Comment 13 by 42576172...@developer.gserviceaccount.com, Sep 18 2017


=== 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:v8:effective_size_avg/background_search/background_search_google

Revision             Result                   N
chromium@447162      11031253 +- 1411371      21      good
chromium@447217      11230272 +- 1730951      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=background.search.google 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/8968101487848929152


For feedback, file a bug with component Speed>Bisection
Status: WontFix (was: Assigned)
Closing because bisect didnt' repro.

Sign in to add a comment