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.
OS: Mac OS X → Linux
Hardware: x86 → x86_64
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
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.
Since bug 1101974 has been cleared from comment 2, unassigning from myself.
Assignee: mchang → nobody
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.
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.
(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).
this has shipped and has no activity, mind if I close this as wontfix?
(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).
thanks- looking forward to the work Bas does when it lands!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.