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

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


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

chromium-rel-win8-dual

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

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

Hi sugoi@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 : sugoi
  Commit : 7ae2ba1892a8b4dee8d7c231ac0e0fbe66588912
  Date   : Sat Mar 25 13:59:47 2017
  Subject: Solving some telemetry tests' slowness

Bisect Details
  Configuration: win_8_perf_bisect
  Benchmark    : media.tough_video_cases_tbmv2
  Metric       : cpu_time_percentage_avg/video.html?src_garden2_10s.webm
  Change       : 62.67% | 0.16839759288 -> 0.273927412372

Revision             Result                      N
chromium@459649      0.168398 +- 0.0162549       9      good
chromium@459650      0.167512 +- 0.00810391      6      good
chromium@459651      0.281794 +- 0.101184        6      bad       <--
chromium@459653      0.284443 +- 0.0834382       6      bad
chromium@459656      0.284211 +- 0.136052        9      bad
chromium@459662      0.273927 +- 0.147044        9      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=video.html.src.garden2.10s.webm media.tough_video_cases_tbmv2

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

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


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

Hi Dale,

  Looking at the graphs together, it looks like the regression is actually from a fix that fixed an issue that predates the origin of some of the graphs.

  All graphs that start before March 15th show a dip a few days before and a restoration to a normal point around March 25th.

 The graphs that start on March 15th seem to show a regression, but that's probably because an issue was there when the graphs were created.

  What do you think?

Not sure what you're asking. Can you elaborate? I agree it seems like this fixed a previous issue for some cases, but there do seem to be new regressions here.

Per the e-mail I just replied too I thought the regressions were in audio-only content, but that doesn't seem to be the case here.

The regression that is mentioned here is "cpu_time_percentage_avg". It's completely normal that it increased after the fix, because before the fix, the cpu was indefinitely idle waiting for a GPU notification that was never happening.

So my point was that before the fix, the cpu_time_percentage_avg" data was bad, and the fix brings it back to normal.

Sounds like this issue is WontFix. Feel free to re-open if you disagree!

Thanks for the investigation, sugoi@!

 Issue 706868  has been merged into this issue.

 Issue 706873  has been merged into this issue.

 Issue 706887  has been merged into this issue.

 Issue 706886  has been merged into this issue.

 Issue 706889  has been merged into this issue.

 Issue 706928  has been merged into this issue.

 Issue 706888  has been merged into this issue.

 Issue 710132  has been merged into this issue.