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

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


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

android-webview-nexus6

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

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

Hi altimin@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 : altimin
  Commit : f39f12be44e4d35eb25c7a58b1895c751da723f5
  Date   : Tue May 30 17:53:12 2017
  Subject: [scheduler] Add general task queue to fix touch latency regression.

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : v8.runtimestats.browsing_mobile
  Metric       : Total:duration_avg/browse_social/browse_social_instagram
  Change       : 30.68% | 12841.87 -> 16781.4183333

Revision             Result                  N
chromium@475581      12841.9 +- 246.531      6      good
chromium@475590      12819.1 +- 212.452      6      good
chromium@475591      16836.6 +- 232.194      6      bad       <--
chromium@475592      16705.2 +- 208.086      6      bad
chromium@475594      16762.5 +- 362.36       6      bad
chromium@475598      16773.5 +- 236.148      6      bad
chromium@475615      16781.4 +- 303.057      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=browse.social.instagram v8.runtimestats.browsing_mobile

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8977891684396083520

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6406305184481280


| 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 Speed>Bisection.  Thank you!

This effect is somewhat expected: my change expands existing mechanism which blocks tasks during touch gesture to ensure the smooth scrolling. Particularly, the patch marks more task categories as blockable.

So I'm inclined to say that this is expected (note that all regressions mentioned are mobile-only as expected due to touch gesture handling being mobile-specific) and close as WontFix. Adding mythria@ as the owner of the benchmark for the final decision.

I think in V8 we measure the wall clock time (and not the CPU time). So, suspending a task will contribute to the currently active bucket on  V8. Since, this cl blocks/suspends more tasks which include V8 tasks, this regression is kind of expected. Also adding cbruni@ who implemented the runtime stats metric in V8.

Just to update, I had an offline discussion with altimin@, the change to block the tasks only delays scheduling of the tasks but it should not suspend an already running V8 task. So, the fact that we measure wall clock time, may not have such a large impact. It could be possible that since the scheduling is different we may execute more javascript code that causes these regressions.

 Issue 729632  has been merged into this issue.

 Issue 730552  has been merged into this issue.

Update: turns out that after my patch test just takes longer to complete. In particular, Tab.WaitForJavaScriptCondition duration tripled from 7 seconds to 21 seconds. This means more code executed and more time spent in v8.

So this regression is not about v8, it's about test duration. I'm still investigating the root cause.

 Issue 733224  has been merged into this issue.

 Issue 733229  has been merged into this issue.

Seems fixed now!

Gerrit failed to link the commit. There's the fix in question: https://chromium-review.googlesource.com/c/525814/.