1498982 - 9.11 - 9.21% Resident Memory (linux64, linux64-stylo-sequential) regression on push ba0c3051a9ed (Fri Oct 12 2018)

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Ionuț Goldan [:igoldan]]

We have detected an awsy regression from push:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=81c3640eaebc47516247f546b2203ec550fdd37a&tochange=ba0c3051a9ed3b8e3120eb25d770ea459d3f719d

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

  9%  Resident Memory linux64 opt stylo                                 550,110,125.90 -> 600,775,321.51
  9%  Resident Memory linux64-stylo-sequential opt stylo-sequential     538,109,206.50 -> 587,153,892.85


You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=16760

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the jobs in a pushlog format.

To learn more about the regressing test(s), please see: https://wiki.mozilla.org/AWSY/Tests

Comment 1

[Sotaro Ikeda [:sotaro]]

Difference of visual seemed to cause the memory regression.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

The visuals can have various buffers like front/back buffers, depth, stencil. The selected buffer depends on the actual gfx driver. With this patch we'll always use GL/WebRender compatible visuals which can raise the memory consumption.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

I don't think there's a fix for that unless we disable the HW acceleration.

Comment 4

[Ionuț Goldan [:igoldan]]

(In reply to Martin Stránský [:stransky] from comment #3)
> I don't think there's a fix for that unless we disable the HW acceleration.

So... Can we call this a wontfix then?

Comment 5

[Karl Tomlinson (:karlt)]

Is there a reason why libGL is loaded even when GL rendering is disabled?

Comment 6

[Sotaro Ikeda [:sotaro]]

(In reply to Karl Tomlinson (:karlt) from comment #5)
> Is there a reason why libGL is loaded even when GL rendering is disabled?

Yea, we could disable to load libGL when GL rendering is disabled.

Comment 7

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Get GL/WebRender compatible visual only when it is necessary necessary.

Comment 8

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Use GL/WebRender compatible visual only when it is necessary necessary

Add comment.

Comment 9

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Use GL/WebRender compatible visual only when it is necessary necessary

Comment 10

[Sotaro Ikeda [:sotaro]]

https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=205707970&revision=d1dbb3c8e92c36ba8681315a7314db952f59d9f4

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/085738995db1
Use GL/WebRender compatible visual only when it is necessary necessary r=nical

Comment 12

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/085738995db1

Comment 13

[Ionuț Goldan [:igoldan]]

I confirm the push from comment 11 fixed the regressions. Thank you!

== Change summary for alert #16867 (as of Tue, 16 Oct 2018 10:25:32 GMT) ==

Improvements:

  6%  Resident Memory linux64-stylo-sequential opt stylo-sequential     579,434,924.94 -> 546,685,771.36
  5%  Resident Memory linux64 opt stylo                                 590,540,933.45 -> 563,223,022.88

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=16867