Reduce core counts for a number of builders#110142
Merged
bors merged 2 commits intorust-lang:masterfrom Apr 15, 2023
Merged
Conversation
rustbot
added
A-testsuite
Mark-Simulacrum
force-pushed
the
reduce-core-counts
branch
from
05a3a66 to
68dcadd
Compare
deltragon
reviewed
Apr 10, 2023
This will allow moving jobs between 8 and 16 core VMs in the next commit more easily.
These builders aren't particularly high on overall average CPU usage and finish in typically around 30 minutes. Cutting their core counts will hopefully not significantly increase wall-time while cutting costs, allowing us to shift some of the wins into our slower builders.
Mark-Simulacrum
force-pushed
the
reduce-core-counts
branch
from
68dcadd to
3153eaa
Compare
Member
|
@bors r+ |
Collaborator
bors
added
S-waiting-on-bors
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Apr 11, 2023
…, r=pietroalbini Reduce core counts for a number of builders Best reviewed by-commit; first commit renames all builder names to include core counts. Applied changes for these builders (only on the auto branch, haven't touched PR CI): - arm-android -> 8 core (currently at 39 minutes; 25.58% CPU) - armhf-gnu -> 8 core (currently at 31 minutes; 30.97% CPU) - dist-aarch64-linux -> 8 core (currently at 35 minutes; 55.38% CPU) - dist-android -> 8 core (currently at 18 minutes; 43.03% CPU) - dist-armhf-linux -> 8 core (currently at 27 minutes; 54.71% CPU) - dist-armv7-linux -> 8 core (currently at 29 minutes; 50.33% CPU) - dist-i586-gnu-i586-i686-musl -> 8 core (currently at 27 minutes; 48.31% CPU) - dist-i686-linux -> 8 core (currently at 32 minutes; 52.39% CPU) - dist-mips-linux -> 8 core (currently at 25 minutes; 55.09% CPU) - dist-mips64-linux -> 8 core (currently at 25 minutes; 55.33% CPU) - dist-mips64el-linux -> 8 core (currently at 26 minutes; 54.93% CPU) - dist-mipsel-linux -> 8 core (currently at 25 minutes; 55.38% CPU) - dist-powerpc-linux -> 8 core (currently at 26 minutes; 55.77% CPU) - dist-powerpc64-linux -> 8 core (currently at 27 minutes; 55.03% CPU) - dist-powerpc64le-linux -> 8 core (currently at 27 minutes; 54.95% CPU) - dist-riscv64-linux -> 8 core (currently at 26 minutes; 54.43% CPU) - dist-s390x-linux -> 8 core (currently at 30 minutes; 55.97% CPU) - dist-various-1 -> 8 core (currently at 36 minutes; 29.16% CPU) - dist-various-2 -> 8 core (currently at 27 minutes; 32.69% CPU) - dist-x86_64-freebsd -> 8 core (currently at 27 minutes; 51.69% CPU) - dist-x86_64-illumos -> 8 core (currently at 30 minutes; 54.88% CPU) - dist-x86_64-musl -> 8 core (currently at 39 minutes; 57.56% CPU) - dist-x86_64-netbsd -> 8 core (currently at 26 minutes; 55.82% CPU) - mingw-check -> 8 core (currently at 17 minutes; 35.00% CPU) - test-various -> 8 core (currently at 22 minutes; 44.84% CPU) - wasm32 -> 8 core (currently at 19 minutes; 62.94% CPU) - x86_64-gnu -> 8 core (currently at 32 minutes; 50.31% CPU) - x86_64-gnu-stable -> 8 core (currently at 32 minutes; 51.23% CPU) - x86_64-gnu-aux -> 8 core (currently at 22 minutes; 46.39% CPU) - x86_64-gnu-debug -> 8 core (currently at 21 minutes; 53.93% CPU) - x86_64-gnu-distcheck -> 8 core (currently at 38 minutes; 55.93% CPU) - x86_64-gnu-llvm-15 -> 8 core (currently at 34 minutes; 52.99% CPU) - x86_64-gnu-llvm-14 -> 8 core (currently at 34 minutes; 52.09% CPU) - x86_64-gnu-llvm-14-stage1 -> 8 core (currently at 33 minutes; 51.13% CPU) - x86_64-gnu-nopt -> 8 core (currently at 29 minutes; 53.36% CPU) - x86_64-gnu-tools -> 8 core (currently at 22 minutes; 40.56% CPU) We may also want to look at merging some of these builders in the future (to deduplicate stage0 builds and such) but that can happen separately - and is more work than just adjusting core counts. r? `@pietroalbini`
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
Collaborator
|
Finished benchmarking commit (fef27e0): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Best reviewed by-commit; first commit renames all builder names to include core counts.
Applied changes for these builders (only on the auto branch, haven't touched PR CI):
We may also want to look at merging some of these builders in the future (to deduplicate stage0 builds and such) but that can happen separately - and is more work than just adjusting core counts.
r? @pietroalbini