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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=a2a4a9f1eac2e5e4499759cb525390daa73cb1139e1879db1ec61ea74475c697


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

chromium-rel-mac11

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

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

Hi piman@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Antoine Labour
  Commit : b5edb4f2db00acedc8726ba4fbdcbf03a9ae7d49
  Date   : Fri Sep 15 01:26:06 2017
  Subject: gpu: don't allow reentrancy in GpuChannelHost::Send

Bisect Details
  Configuration: mac_10_11_perf_bisect
  Benchmark    : scheduler.tough_scheduling_cases
  Metric       : queueing_durations/raf_animation.html
  Change       : 40.38% | 0.0767145945196 -> 0.10769507837

Revision             Result                       N
chromium@502100      0.0767146 +- 0.00336531      6      good
chromium@502116      0.0757452 +- 0.00698359      6      good
chromium@502120      0.0764646 +- 0.00200238      6      good
chromium@502122      0.0763902 +- 0.00246389      6      good
chromium@502123      0.0755916 +- 0.00249347      6      good
chromium@502124      0.107489 +- 0.00367337       6      bad       <--
chromium@502131      0.107027 +- 0.00520527       6      bad
chromium@502162      0.107695 +- 0.00165373       6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=raf.animation.html scheduler.tough_scheduling_cases

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8968030665550102560


For feedback, file a bug with component Speed>Bisection

 Issue 766553  has been merged into this issue.

I'm gathering a debug trace from the bot, but I suspect this will be a wontfix.
The regression is ~30µs, i.e. very low. It shows up as a large % because the baseline is also very low (~75µs) - we're in a good case (no queuing), so we're just measuring the thread wakeup time / kernel scheduling - this is not the type of regression the metric is meant to catch. It is also very sensitive to the scheduling of tasks in other threads. From local testing (that I need to verify against the bot trace), the reason for the regression is that a task on the IO thread moves from after the BeginMainFrame start to before it. The reason for *that* is that the patch actually improves overall cost (GpuChanelHost::Send ends up taking fewer locks), and we actually see an improvement of ~100µs from the beginning of Scheduler::OnBeginImplFrameDeadline to the beginning of BeginMainFrame.

Marking WontFix. Debug traces confirm that we're seeing tiny scheduling differences, which affect that particular metric in negative ways but definitely show improvement in overall performance (e.g. 4-5% improvement in thread_total_all_cpu_time_per_frame).