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

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


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

win-high-dpi

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

=== BISECT JOB RESULTS ===
Bisect failed for unknown reasons

Please contact the team (see below) and report the error.


Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : system_health.common_desktop
  Metric       : story:power_avg/browse_news/browse_news_cnn


To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=browse.news.cnn system_health.common_desktop

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

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


For feedback, file a bug with component Speed>Bisection

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

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : system_health.common_desktop
  Metric       : story:power_avg/browse_social/browse_social_facebook_infinite_scroll

Revision             Result                   N
chromium@505576      12.0201 +- 0.62486       21      good
chromium@505653      11.9504 +- 0.442722      21      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=browse.social.facebook.infinite.scroll system_health.common_desktop

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

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


For feedback, file a bug with component Speed>Bisection

It was a fluke, it seems.

FWIW, looking at the graphs: They all seem to be remaining higher. So, if the bisect isn't catching anything, should we assume the testing environment has changed to a new norm somehow?

I'll try one more time with a wider-rang bisect just in case.

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

=== BISECT JOB RESULTS ===
Bisect failed for unknown reasons

Please contact the team (see below) and report the error.


Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : system_health.common_desktop
  Metric       : story:power_avg/load_search/load_search_baidu


To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=load.search.baidu system_health.common_desktop

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

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


For feedback, file a bug with component Speed>Bisection

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

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

Hi mattm@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 : Matt Mueller
  Commit : 9bcbb136c5284c24bc06d138eb7981c055206b38
  Date   : Sun Oct 01 21:44:02 2017
  Subject: Add der2ascii and der output options to net/tools/print_certificates.py

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : system_health.common_desktop
  Metric       : story:power_avg/load_games/load_games_bubbles
  Change       : 45.00% | 1.37949675989 -> 0.758706302141

Revision             Result                     N
chromium@505522      1.3795 +- 3.09775          6      good
chromium@505523      0.679516 +- 0.0431627      6      bad       <--
chromium@505524      0.708743 +- 0.0612414      6      bad
chromium@505526      0.691148 +- 0.0299962      6      bad
chromium@505529      0.699361 +- 0.0450484      6      bad
chromium@505536      0.691351 +- 0.0193162      6      bad
chromium@505550      0.702371 +- 0.0158643      6      bad
chromium@505577      0.707944 +- 0.0357891      6      bad
chromium@505632      0.722016 +- 0.036194       6      bad
chromium@505742      0.758706 +- 0.0361949      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=load.games.bubbles system_health.common_desktop

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

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


For feedback, file a bug with component Speed>Bisection

Somehow I'm doubting this change caused the regression, unless this script is generating something that could affect the runtime performance of a full browser. Matt, WDYT?

+Charlie and Ned: the bisect in #11 looks like maybe the result just went down on every run. Any ideas?

#12: Indeed, this script is purely for manual usage, not used by the browser or the build at all.

Looking at the traces, the 'good' run has one run (the first one) that reports using 4 watts of power on average. 'Good' here is defined as the run with the higher usage (505522). The 'bad' revision is 505742.

First run from 'good':
https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/load_games_bubbles_2017-10-06_15-03-22_52560.html


second run from 'good':
https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/load_games_bubbles_2017-10-06_15-04-39_51619.html


First run from 'bad':
https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/load_games_bubbles_2017-10-06_15-17-22_4216.html


second run from 'bad':
https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/load_games_bubbles_2017-10-06_15-18-38_55399.html


Between the first and second run of 'good' you can see a large gap between cpu start tracing and battor start tracing, but that also exists between the first and second runs of 'bad' so we can safely ignore that as a cause I think. Since the rest of the runs after the initial high power usage run are similar to the results from other revisions, I think we can focus on the difference between run 1 and run 2 of the 'good' revision.


CPUSnapshots after 'Successful Load:

First run from 'good':
Snapshot 1
chrome gpu-process   12
chrome browser        6
tsproxy               6
wpr                   6

Snapshot 2
chrome renderer      55
chrome browser       24
chrome gpu-process   24
System               18

Snapshot 3
chrome renderer      36
chrome browser       36
chrome gpu process   24
dwm.exe               6
System                6
wmiprvse.exe          6

Snapshot 4
chrome renderer      30
chrome gpu process   18
chrome browser       12
System               12
dmw.exe               6
Explorer.EXE          6
nscp.exe              6

Second run from 'good'
Snapshot 1
Everything reads 0

Snapshot 2 
chrome renderer      36
chrome gpu process   12
chrome browser        6
nscp                  6
system                6
wmiprvse.exe          6

Snapshot 3
chrome renderer      54
chrome gpu process   30
chrome browser       36
system               12

Snapshot 4
chrome renderer      49
chrome gpu process   24
dwm.exe               6


The snapshots are not always taken at the exact same time during a trace, so its not possible to get the whole picture from this, but it appears that chrome is ramping up to higher percentages faster and staying there. There also appears to be more going on in 'system' during the high power run. The cause could be either of them, but I'm not good enough at traversing through traces to dig deeper into the differences between the runs.

Either way, I think its safe to say that the bisect did not find the culprit and the root cause is something to do with the environment. 

The root cause of the bisect showing that cl as the culprit* I only looked at that bisect, so cant comment on the regression as a whole. 

Going to close this as WontFix based on the fact that Randy's analysis convincingly showed that the bisect was incorrect, and identifying the real culprit at this point (~1m after the regression) is likely going to be hard and not too worthwhile.