1736357 - 3.2% Base Content Explicit (Windows) regression on Wed October 13 2021

Status: RESOLVED WONTFIX

(Core :: Memory Allocator, defect, P2)

Description

[Acasandrei Beatrice (needinfo me)]

Perfherder has detected a awsy performance regression from push 8679a50bd45a377a51df66e736c3801bbc1dc1f6. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
3%	Base Content Explicit	windows10-64-2004-shippable-qr		8,112,368.00 -> 8,371,696.00

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
6%	Base Content Heap Unclassified	linux1804-64-shippable-qr	fission	2,064,687.00 -> 1,942,586.33
6%	Base Content Heap Unclassified	linux1804-64-shippable-qr		2,069,529.00 -> 1,949,781.67
5%	Heap Unclassified	macosx1015-64-shippable-qr	fission tp6	137,659,062.78 -> 130,560,838.51
3%	Base Content JS	macosx1015-64-shippable-qr		1,839,810.67 -> 1,782,668.00
3%	Base Content JS	linux1804-64-shippable-qr		1,836,650.00 -> 1,779,960.67
...	...	...	...	...
3%	Heap Unclassified	linux1804-64-shippable-qr	fission tp6	235,574,469.18 -> 229,589,143.47

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1669392

Comment 2

[Paul Bone [:pbone]]

Bug 1669392 increased fragmentation in this test:

├──4.60 MB (182.95%) -- heap-overhead
│ ├──3.33 MB (132.53%) -- bin-unused
│ │ ├──-0.84 MB (-33.28%) ── bin-2048 [8]
│ │ ├──0.75 MB (29.98%) ── bin-3072 [8] [+]
│ │ ├──0.70 MB (27.82%) ── bin-1536 [8] [+]
│ │ ├──0.59 MB (23.33%) ── bin-2560 [8] [+]
│ │ ├──0.44 MB (17.50%) ── bin-3840 [8] [+]
│ │ ├──0.37 MB (14.54%) ── bin-2816 [8] [+]
│ │ ├──0.30 MB (11.98%) ── bin-3584 [8] [+]
│ │ ├──0.29 MB (11.43%) ── bin-768 [8] [+]
│ │ ├──0.25 MB (09.98%) ── bin-3328 [8] [+]
│ │ ├──0.23 MB (09.23%) ── bin-1280 [8] [+]
│ │ ├──0.21 MB (08.40%) ── bin-2304 [8] [+]
│ │ ├──-0.20 MB (-08.13%) ── bin-1024 [8]
│ │ ├──0.18 MB (07.08%) ── bin-1792 [8] [+]
│ │ └──0.07 MB (02.68%) ++ (19 tiny)
│ ├──1.15 MB (45.72%) ── page-cache [8]
│ └──0.12 MB (04.70%) ── bookkeeping [8]

• It seems to be just on windows. Linux and MacOS show an improvement.
• I want to see if this difference occurs with larger heaps, in my testing these definitely benefited (on Linux).
• The fragmentation also exists in the parent process, but the benefits in smaller explicit allocations cover for it. This is quite surprising because the parent process is much larger. It leads me to think this is just not an optimisation in Windows, at least as implemented.

Comment 3

[Paul Bone [:pbone]]

When I test tp6 I see that the new changes are mostly a benefit:

https://treeherder.mozilla.org/perfherder/compare?originalProject=autoland&originalRevision=0ea14d85076d178991c5644ca5abe68d89d1136a&newProject=autoland&newRevision=8679a50bd45a377a51df66e736c3801bbc1dc1f6&framework=4&page=1&showOnlyComparable=1&filter=tp6

I think it's best to keep Bug 1669392, but maybe there are further refinements.

Comment 4

[Lougenia Bailey]

:pbone what's the status on this bug? Should this bug be closed?

Comment 5

[Paul Bone [:pbone]]

it's not a problem because this regression came with a lot of benefits. But I want to keep this bug open because I want to investigate further and learn if there's more opportunities for optimisation.

I optimised Bug 1669392 for Linux and verified it there. it improves memory usage on all platforms however base content memory is worse on Windows. So I'd like to see if there's further improvements that can be made for Windows in particular.

Comment 6

[Paul Bone [:pbone]]

I've taken a close look at a windows memory log.

This is the trade off between sloppy allocations to fragmentation. The patches improve sloppy allocations by (for example 208KiB) at the cost of bin-unused (158KiB). This is to be expected, but it'd be nice of the ratio was even better. To further confirm that this is an overall benefit I see an improvement to resident set size by 164KiB.

I recorded an allocation log in Firefox Nightly on Windows 10 for a content process with example.com loaded. I copied that log to a Linux meachine where I used logalloc-replay and got the following results:

	Before	After
Rss	5210112	5042176
Bin-unused	573488	735792
slop	429056	216064

Values are in KiB.

Comment 7

[Paul Bone [:pbone]]

INVALID because this isn't a problem.