1113358 - Regression: Mozilla-Inbound-Non-PGO - CanvasMark - Ubuntu HW 12.04 - 2.9% decrease

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Mason Chang [Inactive] [:mchang]]

Previous: avg 6421.250 stddev 72.383 of 12 runs up to revision 9e7daf4b7c16
New     : avg 6235.042 stddev 42.375 of 12 runs since revision 26dd6674c459
Change  : -186.208 (2.9% / z=2.573)
Graph   : http://mzl.la/1uXCgsc

From bug 1101974.

Comment 1

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

I did some retriggers on tbpl, here is the link with a selected range of changesets:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&fromchange=013212b16059&tochange=88a15054f99f&jobname=Ubuntu%20HW%2012.04%20mozilla-inbound%20talos%20chromez

This test has noise, a 30 day view doesn't scream out as a problem, but this could be a small blip.  Looking on windows, I don't see any concerns.  Linux64 doesn't show the exact same pattern, but it is really hard to tell:
http://graphs.mozilla.org/graph.html#tests=%5B%5B289,131,33%5D,%5B289,131,35%5D%5D&sel=1417880706685.9119,1418928719997.0598,5409.836065573771,7500&displayrange=30&datatype=running

Comment 2

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

after doing some retriggers the newer jobs are posting much lower values- this is within the 'range', but it is odd.  Either this is noise or somewhat related to the lack of reboots which has changed in releng.

mchang, thanks for being on top of this- your patches are definitely off the hook.

Comment 3

[Mason Chang [Inactive] [:mchang]]

Since bug 1101974 has been cleared from comment 2, unassigning from myself.

Comment 4

[Morgan Phillips [:mrrrgn]]

The talos machines still do reboot after running 30 jobs. That being the case, if this decrease is something that tends to drift over time, then pop back up to normal levels in a cycle, it will make a strong case that increased machine uptime (from 'no reboots') is indeed to blame. 

If that does turn out to be the case, I'll experiment with lowering this threshold and/or adding additional pre/post job cleanup tasks to mitigate the issue. Please keep me updated.

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

I can see this coming in from switching to tiling on Linux with bug 1112170 or possibly from the early exit and an extra error message (?) from bug 1110268.  If former, we'd expect some slow down, and this should be OK.  If later, it'd be interesting to understand why.

Comment 6

[Nicolas Silva [:nical]]

(In reply to Milan Sreckovic [:milan] from comment #5)
> I can see this coming in from switching to tiling on Linux with bug 1112170

This made it possible to use tiling on Linux when the pref layers.enable-tiles is set to true (still false by default).

> or possibly from the early exit and an extra error message (?) from bug
> 1110268.  If former, we'd expect some slow down, and this should be OK.  If
> later, it'd be interesting to understand why.

I'd be a bit surprised since the added code path is only taken in a state where we would always crash before the patch. If we fear that the added log in the branch may have messed with some inlining optimization or whatnot, we can just remove it and see if it changes anything (i'd do that rather than backout the patch since the patch fixes a fair amount of crashes).

Comment 7

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

this has shipped and has no activity, mind if I close this as wontfix?

Comment 8

[Nicolas Silva [:nical]]

(In reply to Joel Maher (:jmaher) from comment #7)
> this has shipped and has no activity, mind if I close this as wontfix?

No problem. Bas is working on something that should address a big performance killer with canvas 2d at the moment, so the situation will improve here (although his stuff is not directly related to this regression which we didn't quite figure out).

Comment 9

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

thanks- looking forward to the work Bas does when it lands!