1139019 - 2.11% MacOS 10.8 kraken regression on Mozilla-Inbound (v.39) on February 25, 2015 from push 65e87c0b6aef

Status: RESOLVED WONTFIX

(Testing :: Talos, defect)

Description

[Vaibhav (:vaibhav1994)]

Talos has detected a Firefox performance regression from your commit 65e87c0b6aef.  We need you to address this regression.

This is a list of all known regressions and improvements related to your bug:
http://alertmanager.allizom.org:8080/alerts.html?rev=65e87c0b6aef&showAll=1

On the page above you can see Talos 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 Talos jobs in a pushlog format.

To learn more about the regressing test, please see: https://wiki.mozilla.org/Buildbot/Talos/Tests#kraken

Reproducing and debugging the regression:
If you would like to re-run this Talos test on a potential fix, use try with the following syntax:
try: -b o -p macosx64 -u none -t dromaeojs  # add "mozharness: --spsProfile" to generate profile data

To run the test locally and do a more in-depth investigation, first set up a local Talos environment:
https://wiki.mozilla.org/Buildbot/Talos/Running#Running_locally_-_Source_Code

Then run the following command from the directory where you set up Talos:
talos --develop -e <path>/firefox -a kraken

Making a decision:
As the patch author we need your feedback to help us handle this regression.

Our wiki page oulines the common responses and expectations:
https://wiki.mozilla.org/Buildbot/Talos/RegressionBugsHandling

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

the build was broken for the set of changes here:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e847b1ee714d&tochange=65e87c0b6aef

I think bhacket is probably responsible, but dvander could help debug this as his change caused the confusion.

We need to know determine which patch is responsible for the change and if there is anything we should do.  This is a small regression on a single platform, so we shouldn't invest tens of hours into fixing this.

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

My checkin wouldn't have caused this.

Comment 3

[Robert Strong (they/them - no direct email)]

I highly doubt Bug 897031 could have caused this. I'm fine with that patch being backed out to exonerate it.

Comment 4

[Markus Stange [:mstange]]

Same for bug 1135912 and bug 961887 - very unlikely.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

:bhackett might have a better idea:)

Comment 6

[Brian Hackett [Laid off!]]

This is probably bug 826741 (changing our default register allocator), it looks like the new allocator is a bit slower than lsra on one of the kraken tests.  This isn't cause to back out bug 826741 as that bug unblocks a fair amount of other work, but I'll try to look at what the problem is in the next few weeks.

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

Thanks Brian.  I agree there is no need to backout or make this fix a P1.  If you need help running kraken locally or talos locally or on try server, do let me know.

Comment 8

[Joel Maher ( :jmaher ) (UTC -8)]

Brian, can you comment on the status of this?  We are uplifting today to Aurora- if this is not something you can work on or fix without a lot of work, please close this as wontfix.

Comment 9

[Brian Hackett [Laid off!]]

This regression isn't going to be fixed in this release.  There are some backtracking allocator improvements coming, mainly bug 1067610, but work on this allocator is currently blocked on removal of our old allocator, LSRA.