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

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


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

win-high-dpi

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

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

Hi jgruber@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 : jgruber
  Commit : 1b5df68365045089eb1f1a661a5bc8a2a1323cc6
  Date   : Tue Aug 22 08:20:54 2017
  Subject: [csa] Fix two cases where allocations could go into LO space

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : media.tough_video_cases_tbmv2
  Metric       : memory:chrome:all_processes:reported_by_chrome:v8:effective_size_avg/video.html?src_garden2_10s.mp4
  Change       : 11.83% | 5136384.0 -> 5743957.33333

Revision                           Result                 N
chromium@496241                    5136384 +- 0.0         6      good
chromium@496269                    5136384 +- 0.0         6      good
chromium@496283                    5136384 +- 0.0         6      good
chromium@496290                    5136384 +- 0.0         6      good
chromium@496292                    5136384 +- 0.0         6      good
chromium@496293                    5136384 +- 0.0         6      good
chromium@496293,v8@9a6f2eec19      5136384 +- 0.0         6      good
chromium@496293,v8@1b5df68365      5743957 +- 478607      6      bad       <--
chromium@496293,v8@748b717763      5656576 +- 0.0         6      bad
chromium@496294                    5918720 +- 642119      6      bad
chromium@496297                    5743957 +- 478607      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=video.html.src.garden2.10s.mp4 media.tough_video_cases_tbmv2

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

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


For feedback, file a bug with component Speed>Bisection

Looks like a flaky benchmark to me.

 Issue 758532  has been merged into this issue.

jgruber@, can you elaborate? 

The "bad" values appear to all be significantly above the "good", and your CL (at a glance) does appear to be making changes to memory allocations. Seems like it could be a real regression.

Just noticed the duplicate Issue - gonna go ahead and re-open this to be sure it isn't lost. LMK why you think its just flaky. 

The graphs (e.g. https://chromeperf.appspot.com/report?sid=0fd3eefe55675ff1b1136cdcea7012959363d25eae5fa64a1cfb19d36836049a&start_rev=483901&end_rev=497159) oscillate between two values, seemingly at random and unrelated to the actual commit range.

The size delta is 520K in old space. gc folks, could this be an additional allocated page?

Yes that is an additional page.

My understanding is that the jumps in the graph happen because we're close to the page limit in old space. When it's exceeded, a whole new page is allocated, causing the 512K (+ some spare change) jumps.

My CL (#3) only makes sure that very large objects are allocated in the correct space instead of crashing V8.

I still think this is a WontFix. Please feel free to reopen though if there is something else.

Sounds good. Thanks for the details.