Bad bisect, new one here:
https://chromeperf.appspot.com/buildbucket_job_status/9015547267323801488

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


===== SUSPECTED CL(s) =====
Subject : Update blimp build bot args match build/args/blimp_engine.gn
Author  : maniscalco
Commit description:
  
Reorder args so it's easier to spot differences.

Remove gyp_defines because blimp is not designed to build with gyp.

BUG=602696

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

Cr-Commit-Position: refs/heads/master@{#386760}
Commit  : 55bf089c901fb38204b642edc847b6259697ee9e
Date    : Tue Apr 12 19:36:58 2016


===== TESTED REVISIONS =====
Revision                Exit Code   Std. Dev.   Num Values  Good?
chromium@386720         0           N/A         20          good
chromium@386755         0           N/A         20          good
chromium@386758         0           N/A         20          good
chromium@386759         0           N/A         20          good
chromium@386760         1           N/A         20          bad         <-
chromium@386764         1           N/A         20          bad
chromium@386773         1           N/A         20          bad
chromium@386790         1           N/A         20          bad

Bisect job ran on: linux_perf_bisect
Bug ID: 602801

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --also-run-disabled-tests page_cycler.intl_es_fr_pt-BR
Test Metric: Memory_BrowserUsed/http___elmundo.es_
Relative Change: Zero to non-zero
Score: 0.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6406
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9015547267323801488


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

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

Do you think that this could possibly be the cause? There are other tests failing as well, I will start another bisect and see if the result is the same.

https://chromeperf.appspot.com/buildbucket_job_status/9015520022801063168

That one failed to find anything at all, started another at:
https://chromeperf.appspot.com/buildbucket_job_status/9015489673290952576

Actually I did the wrong kind of bisect. return_code bisect here:
https://chromeperf.appspot.com/buildbucket_job_status/9015489579123247856

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


===== TESTED REVISIONS =====
Revision                Exit Code   Std. Dev.   Num Values  Good?
chromium@386746         0           N/A         2           good
chromium@386751         0           N/A         2           bad

Bisect job ran on: linux_perf_bisect
Bug ID: 602801

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --also-run-disabled-tests page_cycler.intl_ko_th_vi
Test Metric: idle_wakeups_total/idle_wakeups_total
Relative Change: 0.00%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6411
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9015489579123247856


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

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

That bisect blames a different CL, which makes sense since the last one didn't seem like it would cause this issue.

https://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6411/steps/Post%20bisect%20results/logs/stdio

This one seems kind of unlikely as well though...
https://codereview.chromium.org/1877233002

Adding CL author.

Started another bisect here with expanded range, that last one might have been too small:
https://chromeperf.appspot.com/buildbucket_job_status/9015486644194651808

Re #3, it's very unlikely that 55bf089c901fb38204b642edc847b6259697ee9e is the cause.  That change updates some build flags for a target that's unrelated to Chrome or these tests.

I agree, that's why I didn't revert and just CC'd you in the off chance I missed something. The next bisect found a different, equally unlikely culprit, feel free to remove yourself from the bug.

Re #11, however, nednguyen did revert it.  I'm going to reland it unless there are objections.

Reland, the test is still failing with the revert.

Sorry for the wrong revert!

No worries!

=== 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 : Make lost context and error message callbacks on GpuControl go to client
Author  : danakj
Commit description:
  
In this we introduce a GpuControlClient, that implementations of
GpuControl will call to notify about the context becoming lost, or of
error messages.

Users of GpuControl implement the client to hear about these states.
The most important users of GpuControl here are:
- GLES2Implementation, which now has 2 base::Callbacks which it forwards
  these events to, if they have been set by the user of the
  GLES2Implementation.
- PPB_Graphics3D_Impl, which acts on these two events.
- PepperVideoEncoderHost, which turns lost context events into a call
  to NotifyPepperError(PP_ERROR_RESOURCE_FAILED).
- mojo::GLES2Context, which forwards the lost context event to a
  registered callback.

Other owners of GpuControl (if they exist) never set callbacks on
CommandBufferProxyImpl or equivalent before, so they don't care to
listen to these events and just opt out of setting the client
altogether.

The main implementations of GpuControl here are:
- CommandBufferProxyImpl, which will now call the client instead of
  owning base::Callbacks for these two events.
- mojo::CommandBufferClientImpl, which notifies its client of lost
  contexts, but has no concept of error messages.
- InProcessCommandBuffer, which will now call the client (on the client
  thread) instead of owning and wrapping base::Callbacks for the lost
  context event. It also has no error messages.

For other implementations of GpuControl there is no chance to lose the
context or generate error messages, and they don't even bother to store
the client since it would go unused.

WebGraphicsContext3D{CommandBuffer}Impl continues to be used for these
callbacks, but it now goes directly to the GLES2Implementation to set
callbacks, instead of bypassing it to the CommandBufferProxyImpl.

The next step will be to have Blink or the ContextProvider directly set
these callbacks on the GLES2Implementation, bypassing the
WebGraphicsContext3DImpls entirely. This isn't possible today as the
two versions of WebGraphicsContext3DImpl (which are
WebGraphicsContext3DCommandBufferImpl and
WebGraphicsContext3DInProcessCommandBufferImpl) each have different
versions of the GpuControl, while both having a GLES2Implementation,
forcing ContextProviderCommandBuffer to route through this fork
when setting the callbacks.

R=piman@chomium.org
BUG= 584497 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

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

Cr-Commit-Position: refs/heads/master@{#386761}
Commit  : 10057772128ab5e67452dc736bf15752dc434ed3
Date    : Tue Apr 12 19:36:59 2016


===== TESTED REVISIONS =====
Revision                Exit Code   Std. Dev.   Num Values  Good?
chromium@386696         0           N/A         5           good
chromium@386731         0           N/A         5           good
chromium@386748         0           N/A         5           good
chromium@386757         0           N/A         5           good
chromium@386759         0           N/A         5           good
chromium@386760         0           N/A         5           good
chromium@386761         1           N/A         5           bad         <-
chromium@386765         1           N/A         5           bad
chromium@386834         1           N/A         5           bad

Bisect job ran on: linux_perf_bisect
Bug ID: 602801

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --also-run-disabled-tests page_cycler.intl_ko_th_vi
Test Metric: warm_times/page_load_time
Relative Change: Zero to non-zero
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6412
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9015486644194651808


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

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

Revert here:
https://codereview.chromium.org/1885903002/

Revert failed. Danakj@, since you are more familiar with what this CL does and probably what the other CLs that rely on it; would you mind doing a manual revert?

This is P1 because the benchmarks keep failing.