[librespot] Cap build parallelism to RAM and raise the rustc thread stack - #28
Merged
Merged
Conversation
Gjuju
force-pushed
the
feat/rebuilder-cargo-check
branch
2 times, most recently
from
August 5, 2026 08:49
d402d46 to
63329a0
Compare
Gjuju
force-pushed
the
feat/rebuilder-cargo-check
branch
2 times, most recently
from
August 14, 2026 16:22
e7008c1 to
9498f0c
Compare
Gjuju
force-pushed
the
feat/rebuilder-cargo-check
branch
from
August 25, 2026 08:28
9498f0c to
47051ea
Compare
Gjuju
force-pushed
the
feat/rebuilder-cargo-check
branch
2 times, most recently
from
September 2, 2026 12:42
9754a28 to
cd528de
Compare
Gjuju
changed the title
Gjuju
force-pushed
the
feat/rebuilder-cargo-check
branch
from
September 8, 2026 07:45
cd528de to
dc8ef7d
Compare
cargo defaults to one rustc per core. On a 4-core 512 MB Pi (3A+, Zero 2 W) that stacks four rustc and drives the board into swap thrash. Budget 512 MB per parallel rustc, clamped to [1, nproc], so boards with 2 GB and up keep the current default. An explicit CARGO_BUILD_JOBS still wins.
On aarch64 a codegen worker thread can overflow its 8 MiB stack and take rustc down with SIGSEGV inside LLVM while compiling librespot-protocol, whose generated functions are very large. It is not the OOM killer and not governed by the job count, so it strikes at random. 16 MiB is the remedy rustc's own diagnostic names, and it costs no measurable time: same board twice, 21m19 vs 21m16 on a Pi 4 and 7m13 vs 7m12 on a Pi 5.
Gjuju
force-pushed
the
feat/rebuilder-cargo-check
branch
from
September 9, 2026 17:45
dc8ef7d to
1c6d071
Compare
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
2 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.
Two independent failures on the on-demand librespot build, one fix each.
Measured on Pi 3B, 3B+, 3A+, Zero 2 W, Pi 4 and Pi 5, all rustc 1.96.0.
Both are plain environment variables, set in
packages/librespot/build.shbefore
rbl_check_cargoso they also cover thecargo install cargo-debitmay trigger, itself a build of some 200 crates.
Jobs
cargo defaults to one rustc per core. On a 1 GB Pi 3B that stacks four rustc
and drives the board into SD thrash. Budget 512 MB per parallel rustc, clamped
to
[1, nproc], so 2 GB and up keeps today's default; an explicitCARGO_BUILD_JOBSstill wins. One board, one variable:Two is the knee — a third job saves 16 s and writes 29% more.
Stack
On aarch64 a codegen worker thread can overflow its stack and take rustc down
with SIGSEGV inside LLVM while compiling
librespot-protocol. It is not theOOM killer and not governed by the job count, so it strikes at random.
RUST_MIN_STACK=16777216is the remedy rustc's own diagnostic suggests, and itcosts no measurable time: the same board run twice, once each way, gave 21m19
against 21m16 on a Pi 4 and 7m13 against 7m12 on a Pi 5.
Together they bring back builds that had stopped completing: a Pi 3A+ and a
Zero 2 W (512 MB) finish at one job, and a 1 GB Pi 3B+ that had failed several
attempts finished the same way. Not a guarantee — one 512 MB board has still
failed with both applied.