Closed Bug 1625200 Opened 5 years ago Closed 5 years ago

Exclude SETA backstop from shadow scheduler results

Categories

(Firefox Build System :: Task Configuration, task, P2)

task

Tracking

(firefox77 fixed)

RESOLVED FIXED
mozilla77
Tracking Status
firefox77 --- fixed

People

(Reporter: ahal, Assigned: ahal)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

We currently run the SETA algorithm as a shadow scheduler, so that we can compare the algorithms we're implementing against it.

However the SETA algorithm has a baked in "backstop" that runs every task every 10th push. We do this so we guarantee we don't miss any failing tasks and so sheriffs have a good merge candidate.

The problem is that we'll want to do something similar with all of the other algorithms as well. And right now, the SETA results look worse than they are as they are scheduling way more tasks because of the backstop, so the comparison is not fair.

Since we will want to share this backstop across algorithms, I propose we pull it out of SETA and into its own OptimizationStrategy. So the strategy we use would look something like skip-unless-schedules-or-seta-or-backstop.

I'd like to implement a 'backstop' strategy, such that it will prevent all other
optimizers from removing tasks under certain conditions (e.g every 10th push).

The nicest way to implement this seems to be an 'All' composite strategy
(similar to 'Either' which this patch renames to 'Any'). This means we could
do something like:

All("seta", "backstop")

which means we would only remove tasks if all substrategies say to remove
tasks.

This allows to nest strategies without having to register ever intermediate
composite strategy first. For example:

All(Any("skip-unless-schedules", "seta"), "backstop")

Prior to this patch, we'd need to register that 'Any' one first and then use it
in the 'All'.

Depends on D68620

We'll want some kind of backstop no matter what optimization algorithm we use.
We don't want to go too long without running any given task so we can find
regressions quickly and have a good merge candidate.

This pulls the logic that handles this out of the SETA strategy and into its
own strategy.

This will also make the SETA shadow scheduler more representative of what the
algorithm is doing.

Note in the future we may find ways to make this backstop more efficient (i.e
only run tasks that didn't run in the last 9 pushes for example).

Depends on D68621

Blocks: 1630266
Pushed by ahalberstadt@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7d1a3690be7d [taskgraph] Implement an 'All' composite strategy, r=tomprince https://hg.mozilla.org/integration/autoland/rev/23bfe65864c1 [taskgraph] Support 'OptimizationStrategy' instances directly in composite strategies, r=tomprince https://hg.mozilla.org/integration/autoland/rev/efffde76e782 [taskgraph] Pull the 10th push backstop out of SETA, r=tomprince

I could have sworn that I caught this conflict, fixed it and resubmitted it to Phabricator.. but I guess the phabricator diff doesn't lie and I either forgot the last step or the command failed and I didn't notice.

Flags: needinfo?(ahal)
Pushed by ahalberstadt@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cd8200c37dd3 [taskgraph] Implement an 'All' composite strategy, r=tomprince https://hg.mozilla.org/integration/autoland/rev/a81b9c7a4324 [taskgraph] Support 'OptimizationStrategy' instances directly in composite strategies, r=tomprince https://hg.mozilla.org/integration/autoland/rev/913568b1ee34 [taskgraph] Pull the 10th push backstop out of SETA, r=tomprince
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
Regressions: 1637383
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: