Issue metadata
Sign in to add a comment
|
1%-59.5% regression in scheduler.tough_scheduling_cases at 387198:387236 |
||||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Apr 15 2016
===== BISECT JOB RESULTS ===== Status: completed === Bisection aborted === The bisect was aborted because The metric values for the initial "good" and "bad" revisions do not represent a clear regression. Please contact the the team (see below) if you believe this is in error. === Warnings === The following warnings were raised by the bisect job: * Bisect failed to reproduce the regression with enough confidence. ===== TESTED REVISIONS ===== Revision Mean Value Std. Dev. Num Values Good? chromium@387220 13.046417 1.911649 12 good chromium@387224 12.453778 1.446378 18 bad Bisect job ran on: android_nexus9_perf_bisect Bug ID: 603921 Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --also-run-disabled-tests scheduler.tough_scheduling_cases Test Metric: mean_main_thread_scroll_latency/mean_main_thread_scroll_latency Relative Change: 14.53% Score: 0 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus9_perf_bisect/builds/1739 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9015305518449256784 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=603921 | 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!
,
Apr 22 2016
Submitted some more bisects.
,
Apr 29 2016
The bisect jobs started on April 22 failed with: "Exception: runtest.py without --run-python-script not supported for Android".
File "/b/build/scripts/slave/runtest.py", line 1526, in _MainAndroid
raise Exception('runtest.py without --run-python-script not supported for '
This is a result of https://codereview.chromium.org/1853643006
,
Apr 29 2016
But that failure has apparently been fixed now: https://codereview.chromium.org/1915183002/ Therefore, restarting bisect jobs.
,
Apr 30 2016
===== BISECT JOB RESULTS ===== Status: completed ===== SUSPECTED CL(s) ===== Subject : Hook up ui::Compositor to Display's BeginFrameSource Author : enne Commit description: This hooks up the first SurfaceFactoryClient to the real BeginFrameSource owned by the OnScreenDisplayClient. This is done by adding an OutputSurfaceClient::SetBeginFrameSource method. As the SurfaceDisplayOutputSurface is also a SurfaceFactoryClient, it can hand the real begin frame source directly to ui::Compositor's scheduler. This allows the removal of some of the browser vsync plumbing, but not all of it. Once the renderer compositors have been hooked up to use this path as well, then this and all of the VSyncObserver code can be ripped out. The BeginFrameSource is created by the BrowserCompositorOutputSurface which updates it based on vsync information that it receives. This BeginFrameSource is passed to the Display (via OutputSurfaceClient), which informs the SurfaceManager that the compositor using that Display should be driven by that BeginFrameSource. The SurfaceManager then informs the SurfaceDisplayOutputSurface about the BeginFrameSource, which passes it into the single thread proxy's cc::Scheduler for that ui::Compositor's instance. Plumbing! The path from SurfaceManager to SurfaceDisplayOutputSurface was added in https://codereview.chromium.org/1673783004, but the rest of the plumbing is new to this patch. CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1821863002 Cr-Commit-Position: refs/heads/master@{#387228} Commit : 19c108580b99c469ed192066310e3162bf8c196e Date : Thu Apr 14 03:37:18 2016 ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@387220 12.9708 0.671363 5 good chromium@387224 13.5952 1.35541 5 good chromium@387226 12.6835 1.56737 8 good chromium@387227 15.113 3.01101 8 good chromium@387228 19.5838 1.01151 8 bad <-- chromium@387236 19.2674 0.743967 5 bad Bisect job ran on: android_nexus9_perf_bisect Bug ID: 603921 Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests scheduler.tough_scheduling_cases Test Metric: mean_main_thread_scroll_latency/mean_main_thread_scroll_latency Relative Change: 48.54% Score: 99.9 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus9_perf_bisect/builds/1767 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9014014123072061392 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5904349566337024 | 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!
,
Apr 30 2016
===== BISECT JOB RESULTS ===== Status: completed ===== SUSPECTED CL(s) ===== Subject : Hook up ui::Compositor to Display's BeginFrameSource Author : enne Commit description: This hooks up the first SurfaceFactoryClient to the real BeginFrameSource owned by the OnScreenDisplayClient. This is done by adding an OutputSurfaceClient::SetBeginFrameSource method. As the SurfaceDisplayOutputSurface is also a SurfaceFactoryClient, it can hand the real begin frame source directly to ui::Compositor's scheduler. This allows the removal of some of the browser vsync plumbing, but not all of it. Once the renderer compositors have been hooked up to use this path as well, then this and all of the VSyncObserver code can be ripped out. The BeginFrameSource is created by the BrowserCompositorOutputSurface which updates it based on vsync information that it receives. This BeginFrameSource is passed to the Display (via OutputSurfaceClient), which informs the SurfaceManager that the compositor using that Display should be driven by that BeginFrameSource. The SurfaceManager then informs the SurfaceDisplayOutputSurface about the BeginFrameSource, which passes it into the single thread proxy's cc::Scheduler for that ui::Compositor's instance. Plumbing! The path from SurfaceManager to SurfaceDisplayOutputSurface was added in https://codereview.chromium.org/1673783004, but the rest of the plumbing is new to this patch. CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1821863002 Cr-Commit-Position: refs/heads/master@{#387228} Commit : 19c108580b99c469ed192066310e3162bf8c196e Date : Thu Apr 14 03:37:18 2016 ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@387205 15.6839 1.0007 8 good chromium@387217 15.1758 0.836494 8 good chromium@387223 16.3235 1.25405 8 good chromium@387226 15.7324 0.624229 5 good chromium@387227 15.2234 0.773172 5 good chromium@387228 18.4298 1.18252 5 bad <-- chromium@387229 17.9805 1.17748 8 bad chromium@387253 18.8708 1.45657 8 bad Bisect job ran on: android_nexus7_perf_bisect Bug ID: 603921 Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests scheduler.tough_scheduling_cases Test Metric: mean_input_event_latency/sync_scroll_offset.html Relative Change: 25.50% Score: 99.5 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_perf_bisect/builds/2947 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9014014128465229824 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5850151273365504 | 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 |
|||||||||||||||||||||||
Comment 1 by rsch...@chromium.org
, Apr 15 2016