PGO scheduling optimizations

RESOLVED DUPLICATE of bug 691675

Status

Release Engineering
General
RESOLVED DUPLICATE of bug 691675
6 years ago
5 years ago

People

(Reporter: armenzg, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
Currently *I* believe we are over-triggering jobs.

* For m-c/m-a we trigger unnecessarily pgo jobs because there is nothing better to do:
https://tbpl.mozilla.org/?jobname=pgo&rev=c61e7c3a232a
** 3 full sets of PGO
https://tbpl.mozilla.org/?tree=Mozilla-Aurora&jobname=pgo&rev=01ae9ced59c6

* For m-a/m-b/m-r we trigger both PGO and non-PGO builds
** I believe we should avoid the non-PGO builds
** It saves CPU build time
** We don't run unit tests and talos for non-PGO builds
** These 3 branches are not as sensitive as the other ones (perhaps not the case for m-b when chemspills)
** e.g.
https://tbpl.mozilla.org/?tree=Mozilla-Aurora&rev=01ae9ced59c6
https://tbpl.mozilla.org/?tree=Mozilla-Beta&rev=0ba53003ae26

[1] http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla-tests/config.py#l1077
That's two separate things:

* on m-c (an much more severely, fx-team and services-central) we trigger periodic PGO whether or not the tip rev has already built PGO, bug 691675

* on m-a/m-b/m-r, we only build PGO, but we confuse the issue by putting PGO in the name of the test jobs, but not the name of the builds, so tbpl winds up showing the builds as non-PGO and the tests (including tests on the nightly build) as PGO, making you think there are two builds when in fact we never build non-PGO on those branches, bug 700924
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 691675
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.