Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/build: increase timeouts or reduce parallelism on darwin-arm-mg912baios builder? #32024

Open
bcmills opened this issue May 14, 2019 · 2 comments
Open

x/build: increase timeouts or reduce parallelism on darwin-arm-mg912baios builder? #32024

bcmills opened this issue May 14, 2019 · 2 comments
Labels
Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone
Unreleased

Comments

@bcmills
Copy link
Contributor

bcmills commented May 14, 2019

There is a strange effect visible in this log on the darwin-arm-mg912baios builder.

The tests are running along fine for a while, and when they get to the (presumably CPU-intensive) hash/* tests they suddenly dropm from ~150s per test to ~19m per test.

The first couple of image tests are similarly slow, but then the builder seems to recover:

ok  	go/parser	89.266s
ok  	go/printer	93.493s
ok  	go/scanner	90.741s
ok  	go/token	91.229s
ok  	go/types	93.029s
ok  	hash	95.535s
lldb: running program
PASS
*** Test killed: ran too long (19m0s).
FAIL	hash/adler32	1145.074s
ok  	hash/crc32	1140.671s
ok  	hash/crc64	1139.541s
ok  	hash/fnv	1137.713s
ok  	html	1136.359s
ok  	html/template	1135.509s
ok  	image	1133.465s
ok  	image/color	1135.193s
ok  	image/draw	91.719s
ok  	image/gif	95.854s
ok  	image/jpeg	102.705s
ok  	image/png	102.427s

I wonder if that implies some sort of resource contention (perhaps a thermal limit?) between the tests — should we reduce the parallelism of that builder to decrease the likelihood of spurious timeouts?

CC @eliasnaur @steeve @bradfitz @dmitshur
@bcmills bcmills added Testing An issue that has been verified to require only test changes, not just a test failure. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 14, 2019
@gopherbot gopherbot added this to the Unreleased milestone May 14, 2019
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label May 14, 2019
@eliasnaur
Copy link
Contributor

Now we have a virtual corellium darwin/arm64 builder, the two iOS device builders could be retired. It means that we'll lose darwin/arm coverage, however. It's up to @steeve who runs the device builders and has a very popular gomobile app deployed.

@steeve
Copy link
Contributor

steeve commented May 14, 2019

I think reducing the parallelism is super fine.

We are looking into deprecating darwin/arm ourselves, although we are not there just yet. Most likely target is september with the release of iOS 13, which means we may be able to deprecate iOS 10, and arm32 with it. That said, we don't need the per-commit granularity, so it's completely fine if it runs like once a day or something, so that we don't discover something is wrong at release time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@steeve @eliasnaur @bcmills @gopherbot