Closed Bug 384829 Opened 18 years ago Closed 6 years ago

Mac Txul regression on 6/14

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INACTIVE

People

(Reporter: sayrer, Unassigned)

References

(
URL
)

Details

(Keywords: perf, regression)

See URL for bonsai regression range.
sigh... tinderbox tweaks are in the range too. :(
URL: 14+10%3A55%3A00&cvsroot=%2Fcvsroot → 14+11%3A30%3A00&cvsroot=%2Fcvsroot
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&hours=24&maxdate=1181865901&legend=0 We had a run at 147ms at 10:52am on 6/14, and the initial rise occurred before Nick changed the timeouts on the other tests. It's been much higher since. I know that one of the spikes in the low area was caused by a landing of the new textframe, not sure about the other.
Keywords: perf, regression
OS: Linux → Mac OS X
I think the enabling/disabling of libxul falls in there, too. Good times...
I was connected to the tinderbox using VNC prior to changing the timeouts on Tp, Tp2 and Tdhtml, to estimate how long the tests were taking. Certainly that is the cause of the spike in Tdhtml on the 14th, and also on the 15th. I didn't change Txul settings at all. Looking at a slightly longer timescale for the Txul results http://people.mozilla.com/~nthomas/Txul-bm-xserve08.png is interesting. The big drop on 05/11 corresponds to bm-xserve08 being rebooted (uptime was 184 days), when bug 384032 was being investigated. I don't really see a significant change from libxul being enabled early on the 12th, and disabled again around midday on the 13th. Is the regression here from the ~ 170 ms prior to the reboot and the ~ 177 ms now, or from the ~ 150 ms of the dip ? Also, has anyone looked at the code changes for bug 381888 ?
Bug 381888 only affects Windows, so that's not it.
(In reply to comment #4) > > Is the regression here from the ~ 170 ms prior to the reboot and the ~ 177 ms > now, or from the ~ 150 ms of the dip ? From the 150ms dip. IIRC, there were some zombie processes running on the mac when it was rebooted. Is there anything external that could have caused the spontaneous rise?
(In reply to comment #6) > From the 150ms dip. IIRC, there were some zombie processes running on the mac > when it was rebooted. Is there anything external that could have caused the > spontaneous rise? My recollection is that there was one zombie left around, and assorted bloat from being up for 184 days (like the kernel using > 400 MB of "real memory"). There was also one Minefield sitting in the dock, which I hadn't realized was a test that had finished but not timed out yet (in the sense of bug 360398).
Following some comments by mento on IRC, I connected to bm-xserve08 to close the terminal window which was open (so that Minefield is the only window open). Alas, this did not help and regressed the Tdhtml time: Build Start Time (PDT) Txul (ms) Tdhtml (ms) 01:51 168 437 02:24 170 518 02:56 174 521 03:28 183 518 01:51 is the baseline of recent values 02:24 is after connecting with Chicken of the VNC, closing terminal, disconnect 03:28 is after connecting again (without allowing other clients to connect), disconnect, and close VNC app I find this all very baffling. Other build guys, got any ideas ?
This is an old old report and it doesn't contain enough information to track down the regression.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.