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

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


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

android-nexus5X
android-one
android-webview-nexus5X
android-webview-nexus6
chromium-rel-mac12

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

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

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

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

Hi sunxd@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 : sunxd
  Commit : eeaf4c2326de12c9b36324a805e46ab933057e54
  Date   : Wed Oct 25 20:52:18 2017
  Subject: cc: Enable mask tiling

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:cc:effective_size_avg/background/after_https_www_google_co_uk_hl_en_q_science
  Change       : 1.28% | 9382464.0 -> 9502720.0

Revision             Result              N
chromium@511528      9382464 +- 0.0      6      good
chromium@511554      9382464 +- 0.0      6      good
chromium@511567      9382464 +- 0.0      6      good
chromium@511574      9382464 +- 0.0      6      good
chromium@511577      9382464 +- 0.0      6      good
chromium@511578      9382464 +- 0.0      6      good
chromium@511579      9502720 +- 0.0      6      bad       <--
chromium@511580      9502720 +- 0.0      6      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

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=https.www.google.co.uk.hl.en.q.science memory.top_10_mobile

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

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


For feedback, file a bug with component Speed>Bisection

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

Suspected Commit
  Author : Alex Moshchuk
  Commit : 9cf0ac139cc65890b9e036f704040c8da332d6e3
  Date   : Wed Oct 25 21:26:19 2017
  Subject: Add field trial testing config for sign-in process isolation.

Bisect Details
  Configuration: mac_10_12_perf_bisect
  Benchmark    : system_health.memory_desktop
  Metric       : memory:chrome:all_processes:reported_by_chrome:cc:effective_size_avg/load_tools/load_tools_gmail
  Change       : 53.77% | 19016176.6667 -> 29240833.3333

Revision             Result                   N
chromium@511557      19016177 +- 2545378      6      good
chromium@511591      19497880 +- 3074574      6      good
chromium@511593      18600009 +- 151349       6      good
chromium@511594      31109197 +- 4133410      6      bad       <--
chromium@511596      30879821 +- 4382075      6      bad
chromium@511600      29897299 +- 2647639      6      bad
chromium@511608      30009257 +- 2230444      6      bad
chromium@511625      30209701 +- 2967126      6      bad
chromium@511693      29240833 +- 1389150      6      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

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=load.tools.gmail system_health.memory_desktop

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

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


For feedback, file a bug with component Speed>Bisection

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

Suspected Commit
  Author : Alex Moshchuk
  Commit : 9cf0ac139cc65890b9e036f704040c8da332d6e3
  Date   : Wed Oct 25 21:26:19 2017
  Subject: Add field trial testing config for sign-in process isolation.

Bisect Details
  Configuration: mac_10_12_perf_bisect
  Benchmark    : system_health.memory_desktop
  Metric       : memory:chrome:all_processes:reported_by_chrome:cc:effective_size_avg/load_tools/load_tools_drive
  Change       : 42.76% | 26574864.0 -> 37939374.6667

Revision             Result                   N
chromium@511557      26574864 +- 80264.9      6      good
chromium@511591      26585787 +- 119652       6      good
chromium@511593      26574864 +- 80264.9      6      good
chromium@511594      37327695 +- 1906388      6      bad       <--
chromium@511596      37417797 +- 1774709      6      bad
chromium@511600      37832859 +- 1852793      6      bad
chromium@511608      37753689 +- 1552710      6      bad
chromium@511625      37002756 +- 552095       6      bad
chromium@511693      37939375 +- 1440053      6      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

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=load.tools.drive system_health.memory_desktop

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

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


For feedback, file a bug with component Speed>Bisection

Keeping this open since there are two different regressions here.

@sunxd: Can you followup?

Theoretically the mask tiling patch should not affect google search page since there is no composited border-radius element. The bisect also shows that the patch is responsible for 1.28% regression. I think it might be a false alert. The other bisects reflect 40%+ regression. I think we still want to merge this into the other issue.

I'll mark this as WontFix since: 1) the bisect that points to my cl reflects 1.28% regression which might not be a false alert; 2) the merged bug is marked as WontFix as well.

FWIW - 1.28% regression is not insignificant for memory in this case. Is there anything you can do to justify further or help explain/fix the regression?

Historically for mask layers, we used to allocate texture that is exactly the mask size, e.g., 10*10 for a 10*10 mask layer. This was because we were not able to tile mask layers. Meanwhile for non-mask picture layers, we allocate with the minimum size of 256*256, e.g., a 10*10 picture layer would get 256*256 texture. It is more reasonable to allocate 256*256 due to memory reuse and alignment.

Now with mask tiling implemented, we decide to have mask layer share the normal picture layer tiling logic. This does have side effect that small mask layers would consume more memory than before, but large mask layers (width > 256 or height > 256) would save memory by not storing texture for its solid color portions 
(which is common as a major usage of mask is to implement border-radius), we also benefit by reusing the allocated tile structure of a destroyed mask layer.

So I think the cost is acceptable.

I'll mark this as WontFix for the reason mentioned in comment #9.