Just a heads up, it looks like this landed sometime last week for platforms
that support PGO.
This has an unintended consequence of making it look like perf data for
integration branches went awol, but in fact you need to switch from looking
at "opt" data to "pgo" data. Unfortunately since we
On 21/01/2019 10:18, Jan de Mooij wrote:
On Fri, Jan 18, 2019 at 10:36 PM Joel Maher wrote:
Are there any concerns with this latest proposal?
This proposal sounds great to me. Thank you!
+1. This seems like the right first step to me.
___
On Fri, Jan 18, 2019 at 10:36 PM Joel Maher wrote:
> Are there any concerns with this latest proposal?
>
This proposal sounds great to me. Thank you!
Jan
On Thu, Jan 17, 2019 at 12:52 PM Jan de Mooij wrote:
>
>> Hi Joel,
>>
>> Can you say more about this point in your original email: "3)
Thanks for asking Jan. I think 16% is the maximum we can save. In talking
with a few more people, I think a middle of the road proposal would be to:
Turn off linux64/windows7/windows10 opt builds+tests on autoland and
mozilla-inbound. Leave them on for mozilla-central and try.
What this does
Hi Joel,
Can you say more about this point in your original email: "3) This will
reduce the jobs (about 16%) we run which in turn reduces, cpu time, money
spent, turnaround time, intermittents, complexity of the taskgraph." It
seems to me that if we remove non-PGO opt builds even on Try, we might
On 17/01/2019 16:42, jmaher wrote:
Following up on this, thanks to Chris we have fast artifact builds for PGO, so
the time to develop and use try server is in parity with current opt solutions
for many cases (front end development, most bisection cases).
Even as someone not making frequent
Following up on this, thanks to Chris we have fast artifact builds for PGO, so
the time to develop and use try server is in parity with current opt solutions
for many cases (front end development, most bisection cases).
I have also looked in depth at what the impact on the integration branches
Earlier today I landed a fix for bug 1517532 that will mean that an
artifact build with MOZ_PGO set will pull artifacts from an automation pgo
build. As a result artifact pgo builds as trigger by a "-p all
--artifact..." will succeed now as well (and consume pgo'd artifacts).
If we end up wanting
>* do we turn off builds as well? I had proposed just the tests, if we decide
>to turn off talos it would make sense to turn off builds.
Would turning off opt builds cause problems if you want to mozregression
an opt build? And would this be an issue? (obviously it might be for
opt-only
+1.
The goal of shippable builds is twofold:
1. to make sure opt builds+tests, or similar (artifact builds?) answer the
question "is my commit good?" as fast as possible, and
2. to make sure shippable builds+tests answer the question "are these
binaries correct and ready to ship, if we decide to
thanks everyone for your comments on this. It sounds like from a practical
standpoint until we can get the runtimes of PGO builds on try and in
integration to be less than debug build times this is not a desirable change.
A few common responses:
* artifact opt builds on try are fast for quick
On Fri, Jan 4, 2019 at 11:57 AM Nicholas Alexander
wrote:
> One reason we might not want to stop producing opt builds: we produce
> artifact builds against opt (and debug, with --enable-debug in the local
> mozconfig). It'll be very odd to have --enable-artifact-build and
> _require_
On Thu, Jan 3, 2019 at 1:47 PM Chris AtLee wrote:
> Thank you Joel for writing up this proposal!
>
> Are you also proposing that we stop the linux64-opt and win64-opt builds as
> well, except for leaving them as an available option on try? If we're not
> testing them on integration or release
Nicholas Alexander wrote on 03.01.19 18:41:
> 1) automation builds need a special configuration piece in place to
> properly support artifact builds. Almost certainly that's not in place for
> PGO builds, since it's such an unusual thing to do: "you want to pack PGO
> binaries into a development
Thank you Joel for writing up this proposal!
Are you also proposing that we stop the linux64-opt and win64-opt builds as
well, except for leaving them as an available option on try? If we're not
testing them on integration or release branches, there doesn't seem to be
much purpose in doing the
On Thu, Jan 3, 2019 at 7:22 PM Steve Fink wrote:
> I get
> quite a bit of value out of the resulting faster hack-try-debug cycles;
> I would imagine it to be at least as useful to have a turnaround time of
> 1 hour for opt vs 2 hours for pgo.
>
+1. The past week I've been Try-debugging (1) an
I don't think its much burden, but when we have code complexity it can add
up with a matter of "how useful is this really.." Even if maintenance
burden is low it is still a tradeoff. I'm just saying I suspect its
possible to do this, but not sure if it is useful in the end (and I'm not
looking to
On 03/01/2019 18:16, Steve Fink wrote:
Good points, but given that most failures will show up debug builds, it
seems like a more relevant metric is the difference between time(Opt) vs
min(time(debug), time(PGO)). Though debug builds may run slow enough
that it boils down to what you said?
On 01/03/2019 10:07 AM, Justin Wood wrote:
on the specific proposal front I can envision us allowing tests to be run
on non-pgo builds via triggers (so never by default, but always
backfillable/selectable) should someone need to try and bisect an issue
that is discovered... I'm not sure if the
On 01/03/2019 09:51 AM, Jonathan Kew wrote:
On 03/01/2019 16:17, jmaher wrote:
What are the risks associated with this?
1) try server build times will increase as we will be testing on PGO
instead of OPT
2) we could miss a regression that only shows up on OPT, but if we
only ship PGO and
I should say that the shippable build proposal (
https://groups.google.com/d/msg/mozilla.dev.planning/JomJmzGOGMY/vytPViZBDgAJ)
doesn't seem to intersect negatively with this.
And in fact I think these two proposals compliment each other quite nicely.
Additionally I have no concerns over this
On 03/01/2019 16:17, jmaher wrote:
I would like to propose that we do not run tests on linux64-opt, windows7-opt,
and windows10-opt.
Why am I proposing this:
1) All test regressions that were found on trunk are mostly on debug, and in
fewer cases on PGO. There are no unique regressions found
On Thu, Jan 3, 2019 at 8:43 AM Brian Grinstead
wrote:
> Artifact builds don’t work with PGO, do they? When I do `-p all` on an
> artifact try push I get busted PGO builds (for example:
> https://treeherder.mozilla.org/#/jobs?repo=try=7f8ead55ca97821c60ef38af4dec01b8bff0fdf3=219655864).
> What's
Would this apply to talos as well? I’ve wondered before if we should care at
all about opt-only talos regressions for platforms where we ship PGO. IME quite
a number of talos changes (both improvements and regressions) only show up on
one or the other, so dropping one would simplify things.
CC Callek
How will this interact with the "shippable builds" project that Callek
posted
about awhile back? My understanding is there's a high probability PGO is
going away. Would it make sense to wait for that to project to wrap up?
-Andrew
On Thu, Jan 3, 2019 at 11:20 AM jmaher wrote:
> I
Artifact builds don’t work with PGO, do they? When I do `-p all` on an artifact
try push I get busted PGO builds (for example:
https://treeherder.mozilla.org/#/jobs?repo=try=7f8ead55ca97821c60ef38af4dec01b8bff0fdf3=219655864).
What's needed to make it work? Requiring a full build for
On 03/01/2019 16:17, jmaher wrote:
What are the risks associated with this?
1) try server build times will increase as we will be testing on PGO instead of
OPT
2) we could miss a regression that only shows up on OPT, but if we only ship
PGO and once we leave central we do not build OPT, this
Can we set it up so we can manually runs tests on opt builds; but they
aren't by default?
I've had many instances where opt (and pgo) fail; but I can't
reproduce a test failure locally and can only do it on try. Letting me
run that test on the opt build will save the additional pgo build time
I would like to propose that we do not run tests on linux64-opt, windows7-opt,
and windows10-opt.
Why am I proposing this:
1) All test regressions that were found on trunk are mostly on debug, and in
fewer cases on PGO. There are no unique regressions found in the last 6 months
(all the data
29 matches
Mail list logo
