1084483 - Disable/remove tracking of peak link.exe memory

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Benjamin Smedberg]

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.

Comment 1

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

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

Comment 2

[Benjamin Smedberg]

What info do you need from me?

Comment 3

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

yeah, that wasn't clear, do you have any objections to me removing this?

Comment 4

[Benjamin Smedberg]

No, I requested it in the first place ;-)

Comment 5

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

Attachment: buildbot custom changes to remove collecting link time statistics (1.0)

Comment 6

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

Attachment: buildbot-configs patch to remove linker statistics (1.0)

Comment 7

[Chris Cooper [:coop] (he/him)]

Can _count_vsize also go away then?

http://mxr.mozilla.org/build/source/mozharness/mozharness/mozilla/building/buildbase.py#1118

Comment 8

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

Attachment: remove *vsize* from mozharness scripts (1.0)

thanks for finding the mozharness bits- I have removed all references to vsize :)

Comment 9

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

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.

Comment 10

[Chris Cooper [:coop] (he/him)]

(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.

Comment 11

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

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.

Comment 12

[Rail Aliiev [:rail]]

In production: https://hg.mozilla.org/build/buildbot-configs/rev/67ed57cae441

Comment 13

[Rail Aliiev [:rail]]

In production: https://hg.mozilla.org/build/buildbotcustom/rev/c8d37797bbd8

Comment 14

[Rail Aliiev [:rail]]

mozharness production tag moved to: https://hg.mozilla.org/build/mozharness/rev/ca580fcfa627

Comment 15

[Rail Aliiev [:rail]]

In production: https://hg.mozilla.org/build/buildbot-configs/rev/67ed57cae441

Comment 16

[Rail Aliiev [:rail]]

In production: https://hg.mozilla.org/build/buildbotcustom/rev/c8d37797bbd8

Comment 17

[Rail Aliiev [:rail]]

mozharness production tag moved to: https://hg.mozilla.org/build/mozharness/rev/4d260376921f