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

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


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

android-nexus9
android-one

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9001716124082211008

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


===== SUSPECTED CL(s) =====
Subject : cc: Remove frame queuing from the scheduler.
Author  : sunnyps
Commit description:
  
CC scheduler has a frame queuing mechanism called "retro frames". This
has been responsible for a lot of complexity and hard to fix bugs. The
original intent for adding retro frames was to allow the scheduler to
handle multiple frames in flight but that goal doesn't seem feasible or
even desirable any more. This CL removes the retro frames queue and
instead makes the Scheduler end the previous frame when it receives a
BeginFrame message.

One surprising behavior was that SyntheticBFS MISSED frames would be
queued as retro frames and this would convert the synchronous begin
frame call (inside Scheduler::ProcessScheduledActions) to an
asynchronous retro frame PostTask. To work around this the Scheduler
keeps track of a single CancelableClosure that's used for MISSED frames.

The above behavior was also causing the BeginFramesNotFromClient tests
to work even though there was an extra MISSED frame in the queue. This
is more elegantly solved in another way by using frame number to advance
the task runner instead of just running pending tasks.

Lastly SchedulerStateMachine is modified so that it's possible to end
the previous frame and still have the same behavior as before in the
commit to active tree (browser compositor) mode.

R=brianderson@chromium.org,enne@chromium.org,danakj@chromium.org
BUG= 602485 ,  644992 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2323063004
Cr-Commit-Position: refs/heads/master@{#417764}
Commit  : 559280b26cc5672f5f054e8ac35281e804c14d78
Date    : Fri Sep 09 23:38:51 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@417724  6138429  61231.5  5  good
chromium@417749  6183157  50159.0  5  good
chromium@417761  6169026  64718.5  5  good
chromium@417763  6294118  38425.5  5  good
chromium@417764  7370383  141171   5  bad    <--
chromium@417767  7472906  495116   5  bad
chromium@417773  7227146  425706   5  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 645965

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests memory.top_10_mobile
Test Metric: foreground-memory:chrome:all_processes:reported_by_os:system_memory:java_heap:proportional_resident_size_avg/http_m_intl_taobao_com_group_purchase_html
Relative Change: 17.74%
Score: 99.9

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


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

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