Disable/remove tracking of peak link.exe memory

RESOLVED FIXED

Status

RESOLVED FIXED
4 years ago
7 months ago

People

(Reporter: benjamin, Assigned: jmaher)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Tracking of the peak memory usage of link.exe was added in bug 710840. Now that we are using a 64-bit compiler/linker toolchain with MSVC2013, this number is not longer interesting, and I suggest that we disable this test. We may not want to totally remove the code for 6 weeks in case a regression forces us to revert back to MSVC2010.
(Reporter)

Updated

4 years ago
Depends on: 710840
(Assignee)

Comment 1

4 years ago
I think enough time has elapsed to consider removing this.  We are still uploading the link data:
http://graphs.mozilla.org/graph.html#tests=[[205,1,8]]&sel=1398101349059,1429637349059&displayrange=365&datatype=geo
Flags: needinfo?(benjamin)
(Assignee)

Updated

4 years ago
Blocks: 1156885
(Reporter)

Comment 2

4 years ago
What info do you need from me?
Flags: needinfo?(benjamin) → needinfo?(jmaher)
(Assignee)

Comment 3

4 years ago
yeah, that wasn't clear, do you have any objections to me removing this?
Flags: needinfo?(jmaher) → needinfo?(benjamin)
(Reporter)

Comment 4

4 years ago
No, I requested it in the first place ;-)
Flags: needinfo?(benjamin)
(Assignee)

Comment 5

4 years ago
Created attachment 8597992 [details] [diff] [review]
buildbot custom changes to remove collecting link time statistics (1.0)
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Attachment #8597992 - Flags: review?(coop)
(Assignee)

Comment 6

4 years ago
Created attachment 8597994 [details] [diff] [review]
buildbot-configs patch to remove linker statistics (1.0)
Attachment #8597994 - Flags: review?(coop)
Attachment #8597994 - Flags: review?(coop) → review+
Attachment #8597992 - Flags: review?(coop) → review+
(Assignee)

Comment 8

4 years ago
Created attachment 8598085 [details] [diff] [review]
remove *vsize* from mozharness scripts (1.0)

thanks for finding the mozharness bits- I have removed all references to vsize :)
Attachment #8598085 - Flags: review?(coop)
Attachment #8598085 - Flags: review?(coop) → review+
(Assignee)

Comment 9

4 years ago
I assume there will need to be an order of operations here.  Some concerns:
1) landing the buildbot* changes will cause mozharness to fail
2) landing mozharness changes need to be on ALL branches (b2g*, esr*, m-r, etc.)
3) I assume once mozharness changes are in then we can land the buildbot changes?

I could use some guidance/confirmation here.
Flags: needinfo?(coop)
(In reply to Joel Maher (:jmaher) from comment #9)
> I assume there will need to be an order of operations here.  Some concerns:
> 1) landing the buildbot* changes will cause mozharness to fail
> 2) landing mozharness changes need to be on ALL branches (b2g*, esr*, m-r,
> etc.)
> 3) I assume once mozharness changes are in then we can land the buildbot
> changes?

The buildbot-config and mozharness implementations are orthogonal, so order-of-landing shouldn't matter. The default in both cases is to pref the vsize collection off, so we should be fine.
Flags: needinfo?(coop)
(Assignee)

Comment 11

4 years ago
buildbotcustom changes:
https://hg.mozilla.org/build/buildbotcustom/rev/c8d37797bbd8

buildbot-config changes:
https://hg.mozilla.org/build/buildbot-configs/rev/67ed57cae441

mozharness changes:
https://hg.mozilla.org/build/mozharness/rev/b8e46610ae63

I will let the natural courses of reconfigs and mozharness updates on branches take effect.
(Assignee)

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.