Decommit unused pages on all platforms

RESOLVED FIXED in Firefox 68

Status

()

enhancement
RESOLVED FIXED
4 months ago
3 months ago

People

(Reporter: gcp, Assigned: gcp, NeedInfo)

Tracking

(Blocks 1 bug)

Trunk
mozilla68
x86_64
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(3 attachments)

https://phabricator.services.mozilla.com/D24135#755563

Decommit unused (base) allocations on all platforms to unify the code.

Assignee: nobody → gpascutto
Blocks: 1537781, 1446040
Summary: Decommit unused base_page allocations → Decommit unused pages on all platforms

I did some checking and the amount of mapping in the master process goes from 2k to 4k. It doesn't necessarily increase quickly if the number of tabs increases. Each content process ends up with 2k to 4k maps as well. So it seems the 64k map limit is no immediate concern, even less in the post Fission world.

Attachment #9056183 - Attachment description: Bug 1542290 - Remove all DECOMMIT/DOUBLE_PURGE logic. r=glandium → Bug 1542290 - Decommit unused pages on all platforms. r=glandium

3-5% performance regression on macOS and Linux, none on Windows (as expected, as it was using this codepath).

This is with guard pages included, but I think the impact of those is minimal (should be mostly AWSY which is minimal), and it's more likely the overhead of mapping in/out on many allocations that we're seeing?

https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=b2db9db56ff5b74f929221afe97f6183f4d7f9e4&framework=1&selectedTimeRange=172800

I'll do a separate Talos run for base_page allocations only, which probably has much less impact.

I'll do a separate Talos run for base_page allocations only, which probably has much less impact.

Somet tests between -5% and +5% but mostly a wash.

Mike, fully unifying the code looks like it has too large an impact on performance (generally 3% loss in page render performance on MacOS and Linux). I will land the simplification for base_pages (no real perf impact) but it looks like we can't take the rest. mmap seems to be a lot slower than madvise, basically.

Out of curiosity I did a Talos test of removing DECOMMIT entirely (so the other way around) to see what it does to Windows performance.

In bug 1537781 I will replace the current patches by a new set that only guards the last page on MacOS/Linux, instead of the entire unused region (which Windows would still do).

Flags: needinfo?(mh+mozilla)
Pushed by gpascutto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bc2550828518
Decommit unused base_page allocations. r=glandium
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

It seems that at least on macOS it was perviously established that using mmap over madvise is a performance loss:
http://jemalloc.net/mailman/jemalloc-discuss/2012-May/000405.html

Type: defect → enhancement
You need to log in before you can comment on or make changes to this bug.