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

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


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

android-nexus5X

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

Hi rockot@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 : Send input event IPCs directly from the UI thread
Author  : rockot
Commit description:
  
This CL:

1. Adds SendNow and SendOnIOThread to ChannelProxy
  2a. SendNow sends immediately from the current thread if the
      underlying Channel implementation claims to have a
      thread-safe Send.
  2b. SendOnIOThread is simply a more explicit alias for Send and
      and does not acknowledge the thread-safety of the
      underlying Channel implementation.
2. Flags ChannelMojo for thread-safe Send once again
3. Adds GetImmediateSender and GetIOThreadSender interfaces to
   RenderProcessHost. These are safe alternatives to using its
   IPC::Sender implementation directly and each corresponds to
   SendNow or SendOnIOThread behavior, respectively.
4. Changes RenderWidgetHostImpl so that the input router uses
   the RPH's immediate Sender interface.

The net result here is that input events are now sent to renderers
directly from the UI thread, and we have a reusable path forward
for porting more IPCs to the SendNow interface.

BUG= 612944 
TBR=jam@chromium.org

Review-Url: https://codereview.chromium.org/1991323002
Cr-Commit-Position: refs/heads/master@{#395906}
Commit  : 868f89e764ab0e807adb237f0cbaf79ca5f49257
Date    : Wed May 25 16:28:06 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N  Good?
chromium@395894  2.89713  0.0342408  5  good
chromium@395904  2.89856  0.0357093  8  good
chromium@395905  2.89411  0.0308957  5  good
chromium@395906  3.00274  0.0243977  5  bad    <--
chromium@395907  2.98568  0.0433504  5  bad
chromium@395909  3.00114  0.0412009  8  bad
chromium@395914  2.99916  0.0275074  5  bad
chromium@395933  3.0238   0.022967   5  bad

Bisect job ran on: android_nexus5X_perf_bisect
Bug ID: 616525

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests thread_times.simple_mobile_sites
Test Metric: thread_browser_cpu_time_per_frame/thread_browser_cpu_time_per_frame
Relative Change: 4.37%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/199
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9011037042290786608


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

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

The CL was reverted for reasons other than performance and won't be relanded. This appears to have recovered the metrics in question.