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

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


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

chromium-rel-mac-retina
chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-mac12

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/149bb50f780000

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/149bb50f780000

Broke some jobs with a dev version, restarting.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14892a37780000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14892a37780000

PageAllocator: Fix DecommitSystemPages() semantics
By ajwong@chromium.org · Tue Oct 17 06:55:31 2017
chromium @ 8a24491093779658b7392f2718e691203bd45fcb

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

This perf regression might caused because now PartitonAlloc sets the page permissions in posix when decommitting.  This was not previously true.  However, there is another regression in http://crbug.com/775949 so am just reverting first and then investigating.

Yeah, Dromaeo is a popular benchmark, so regression on the benchmark is not really acceptable without having a reason to do so :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d51917577500b94fe9894125483073222dff2834

commit d51917577500b94fe9894125483073222dff2834
Author: Albert J. Wong <ajwong@chromium.org>
Date: Thu Oct 26 21:39:43 2017

Revert "PageAllocator: Fix DecommitSystemPages() semantics"

This reverts commit 8a24491093779658b7392f2718e691203bd45fcb.

Caused a 5.4-6.6% DOM rendering performance regression in mac in
dromaeo.domcoremodify and a 15.8% memory usage regression for android
in system_health.memory_mobile.

The perf regression might be explainable by the tightening of the
page protections, but the memory regression doesn't make sense.

Reverting to give time to investigate.

TBR=palmer,haraken

Bug: 775949,  776755 
Change-Id: I7475fe2e384f9846f64da276ee0754ede1b009e9
Reviewed-on: https://chromium-review.googlesource.com/740091
Reviewed-by: Albert J. Wong <ajwong@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Albert J. Wong <ajwong@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511967}
[modify] https://crrev.com/d51917577500b94fe9894125483073222dff2834/base/allocator/partition_allocator/page_allocator.cc
[modify] https://crrev.com/d51917577500b94fe9894125483073222dff2834/base/allocator/partition_allocator/page_allocator.h
[modify] https://crrev.com/d51917577500b94fe9894125483073222dff2834/third_party/WebKit/Source/platform/heap/HeapPage.cpp
[modify] https://crrev.com/d51917577500b94fe9894125483073222dff2834/third_party/WebKit/Source/platform/heap/PageMemory.cpp

Revert should fix it. Closing.