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

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


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

chromium-rel-mac12

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12fc30a0c40000

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12daa4e0c40000

According to the bisect, this CL https://chromium.googlesource.com/chromium/src/+/292df1662cdb1d04f210343aee0f9fc361fd16c6 seems to have cause the regression.

Assigning it to author.

dtu: The bisect didn't assign the author, is that expected?

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

Looks like the bisect job was looking for a second, smaller, regression around r547536-r547541 when the bot died. It won't assign the author in the case of an error.

Do we know if the regression is exclusively on macOS? I am fairly certain that the CL in question did not regress memory on macOS, because it removed a system call that purports to save memory in some situations but which was actually failing in all situations. The net effect should be (a) no memory change and (b) a tiny speedup due to avoiding the unnecessary system call.

I wouldn't rule out the possibility that the system call *reports* failure but actually works. But even so, the way we were handling the failure was to fall back to what is now the only behavior (`madvise(..., MADV_DONTNEED)`). So even of MADV_FREE_REUSABLE succeeded, we would immediately undo our memory-saving work with DONTNEED.

So I don't think this CL is the culprit, at least if the platform is macOS.

Also, 5 to 40% is quite a spread...

I was added as a reviewer on the CL in question, but did not review it. My bad.

According to the CL:
"""
  // MADV_FREE_REUSABLE (macOS): Apparently never worked (EINVAL), and the
  // failure was masked by a retry block intended for Linux in cases when
  // MADV_FREE was defined but not implemented in the running kernel. So we were
  // making an unnecessary system call.
"""

I added the call to MADV_FREE_REUSABLE, and it was confirmed by myself and others to fix accounting for memory on macOS. See https://bugs.chromium.org/p/chromium/issues/detail?id=708797#c32.

It seems likely that the CL called out in c#7 did in fact regress our accounting for memory usage by a large amount. Could you revert that portion of the CL, and then file a bug where we can discuss the EINVAL you're seeing?

#10: I'll put together a CL for that, sure. But you can see what I saw now by looking at patchsets 1, 2, and 3 of https://chromium-review.googlesource.com/c/chromium/src/+/990584/5, and looking at the macOS bot results.

Looking at that CL, I'm observing that there are instances where the syscall fails, not that the syscall always fails.

Ping - could we back out the macOS changes?

#13: I just updated https://chromium-review.googlesource.com/c/chromium/src/+/999155, see if you like it.

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

commit a0d254f59db792363f4698f4a2fab64e99e247e8
Author: Chris Palmer <palmer@chromium.org>
Date: Tue Apr 10 23:40:26 2018

Go back to trying MADV_FREE_REUSABLE on macOS.

But with a fallback, since it's sometimes necessary.

Bug:  828886 
Change-Id: I5ca1a6a6377667f2b950a209310230e8031e6043
Reviewed-on: https://chromium-review.googlesource.com/999155
Reviewed-by: Albert J. Wong <ajwong@chromium.org>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Commit-Queue: Chris Palmer <palmer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549679}
[modify] https://crrev.com/a0d254f59db792363f4698f4a2fab64e99e247e8/base/allocator/partition_allocator/page_allocator_internals_posix.h

This needs to be merged to M-67. It's causing a large shift in our memory metrics. Attaching the Canary graph which shows the movement

Deleted: Screen Shot 2018-04-18 at 9.55.42 AM.png 145 KB

	Screen Shot 2018-04-18 at 9.55.42 AM.png 145 KB View Download

Oh, weird, I thought I got it in before the 67 branch point. But yeah it should be merged back, and it's a simple diff. 

Your change meets the bar and is auto-approved for M67. Please go ahead and merge the CL to branch 3396 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Pls merge your change to M67 branch 3396 ASAP so we can pick it for next M67 Dev/Beta release. Thank you.

#21: I tried the Cherrypick action in Gerritt, and suggested in https://www.chromium.org/developers/how-tos/drover. It said: "Could not perform action: cherrypick failed: identical tree". Does that mean the change is already in 67? That is what I would expect (see #19: I landed the change on the 10th, and we branched on the 12th, per https://chromiumdash.appspot.com/schedule).

My bad, somehow I screwed this up.

The CL's ID is 549679. Branch point of current Mac Dev [m67] is 550428.

I guess integer comparison is hard.