All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=594433

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


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

android-nexus5
android-nexus6

Kicked off another bisect: https://chromeperf.appspot.com/buildbucket_job_status/9017181931978050304

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

Hi penghuang@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 : Get rid of gpu related switches by passing gpu::GpuPreferences via IPC.
Author  : penghuang
Commit description:
  
BUG= 590825 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel

Committed: https://crrev.com/248b114c9d3034964c7259222712dfcccfad8f48
Cr-Commit-Position: refs/heads/master@{#379651}

Review URL: https://codereview.chromium.org/1753383003

Cr-Commit-Position: refs/heads/master@{#380320}
Commit  : 2084d99587adfa5eeb4025d5a12c8856fe8d2f3a
Date    : Thu Mar 10 03:34:55 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@380302         11.967242   0.079544    5           good
chromium@380312         11.962063   0.183262    5           good
chromium@380317         12.072824   0.047227    5           good
chromium@380319         11.95931    0.131451    5           good
chromium@380320         13.192906   0.242649    5           bad         <-
chromium@380321         13.16002    0.138547    5           bad
chromium@380339         13.248458   0.205828    5           bad

Bisect job ran on: android_s5_perf_bisect
Bug ID: 594433

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --also-run-disabled-tests thread_times.key_silk_cases
Test Metric: thread_GPU_cpu_time_per_frame/http___jsfiddle.net_vBQHH_11_show_
Relative Change: 10.71%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_s5_perf_bisect/builds/556
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9017181931978050304


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

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

based on bisect results in c#3, penghuang@ could you please check the issue.

Could you please explain the graphs to me? What does thread_IO_cpu_time_per_frame mean?

My CL just gets rid of most command line flags of gpu process, and passes those gpu preferences via an IPC. I don't see why it can cause any performance issue.

+vmiura, owner of thread_times.key_silk_cases. Victor, can you answer the questions in #5?

Note that on the graphs with individual pages in them, you can click on a tooltip to see a trace. Here's an example from ChromiumPerf/android-galaxy-s5/thread_times.key_silk_cases/thread_IO_cpu_time_per_frame/http___jsfiddle.net_vBQHH_11_show_

Before your CL: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_10-2016-03-09_19-16-55-72722.html
After your CL: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_10-2016-03-09_21-58-01-59429.html

vmiura, can you take a look at the question in #5. Also we should figure out if this is a regression worth caring about, it seems relatively minor.

Ping Victor.

re#5: This is just measuring average CPU time per thread type.  thread_IO_cpu_time_per_frame includes all IO threads.  It looks to me like several thread times have increased.

Passing the GPU preferences by IPC doesn't seem like a problem to me.  I wonder if this CL resulted in some difference in the preference values, since GetGpuPreferencesFromCommandLine() is running on a different processes' command line.

The GPU process gets additional command line options appended at launch, e.g. https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/gpu/gpu_process_host.cc&q=AppendGpuCommandLine&sq=package:chromium&l=1002

zmo@ / ken@: any thoughts?


PS. Come to think of it, was GetGpuPreferencesFromCommandLine() already ignoring these extra options when running in process?

re#9: The additional command line options problem has been fixed with https://codereview.chromium.org/1881463002 . Maybe this issue has been fixed with that CL too.

The main thought I had, which vmiura@ and I discussed in person, is that perhaps there is some initialization code in src/content/gpu/gpu_main.cc whose behavior changes depending on the command line arguments passed in. This code would probably need to be deferred until the GpuMsg_Initialize message is received.

However, the sandbox can't be locked down until GLSurface::InitializeOneOff is called, and that needs to be done early in the GPU process's startup.

penghuang@ : Assigned to you from the below bisect result, could you please take a look into this and update further.

https://codereview.chromium.org/1753383003

Probably this issue have been fixed by https://codereview.chromium.org/1881463002, but I don't know how to verify it. Can anyone help me verify it?