Closed Bug 615535 Opened 15 years ago Closed 15 years ago

Have a Ts run on Linux Talos with disabled barriers

Categories

(Release Engineering :: General, defect, P2)

x86
Linux
defect

Tracking

(blocking2.0 betaN+)

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: mak, Assigned: catlee)

Details

We'd like to have some Ts result from a Linux talos box with ext4 barriers disabled, to figure out if they play a role in the Ts regression we are seeing on the Places branch. So, the request is to have 3-4 Ts runs of a Places branch changeset (http://hg.mozilla.org/projects/places/rev/080549b4c0f8 could be fine) on a linux ext4 box with barriers disabled.
This investigation is currently blocking the Places branch merge to central, thus requesting blocking an bumping up priority a bit.
blocking2.0: --- → ?
Priority: -- → P2
blocking2.0: ? → beta9+
Taking talos-r3-fed-003 out of the pool for this.
Assignee: nobody → catlee
Status: NEW → ASSIGNED
Remounted / with barriers off with # mount / -o remount,barrier=0 Ran Ts 3 times and got these values: 532.84, 522.47, 520.16
So, comparing with our results from the branch boxes (577.09±34.08), barriers are culprit for about 50ms
Thank you very much Chris, you've been very helpful. I think we are done with this measure.
And to compare...mount / -o remount,barrier=1 588.37, 590.11, 591.26. Machine is back in the pool.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
interesting this is a bit more than the 577 we had, so looks more like 60ms
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
blocking2.0: beta9+ → betaN+
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.