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.

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

cargo seems to start several build jobs with -j1 (but doesn't?) #7689

Open
matthiaskrgr opened this issue Dec 9, 2019 · 4 comments
Open
Labels
A-jobserver Area: jobserver, concurrency, parallelism C-bug Category: bug S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@matthiaskrgr
Copy link
Member

Problem
When building cargo itself with cargo build -j1, it looks like it compiles several crates at once sometimes, ignoring my -j1 directive, according to the compile progress output:

 Building [=============================================>         ] 135/160: backtrace-sys(build), libssh2-sys(build), libnghttp2-sys(build), toml

Looking at htop, it does not seem that more than 1 thread is cpu-intensive though.

Steps

  1. cargo build -j1 in the cargo repo

Notes

Output of cargo version:
cargo 1.41.0-nightly (626f0f40e 2019-12-03)
linux 5.3.12-1-MANJARO

@matthiaskrgr matthiaskrgr added the C-bug Category: bug label Dec 9, 2019
@ehuss
Copy link
Contributor

ehuss commented Dec 10, 2019

This is normal for build scripts that use the cc crate. It is related to the concern I mention in #7344 (comment) where the build script has finished its work, but there is a brief window where it needs to drop and then re-acquire a token. During this time, the build script will be in memory, but it shouldn't be doing any work (it's just blocking for the token before it exits).

I haven't (yet) been able to reproduce it actually spawning multiple rustc processes or using multiple CPUs. I can pretty easily reproduce accumulating multiple -sys(build) crates. @matthiaskrgr if you can maybe provide more details of when you see it using multiple CPUs that might help. Like, is it multiple rustc processes? Or is it a single rustc using multiple CPUs? Or is it something else?

One possibility is to alleviate the cc issue is to put a hard cap on the job queue from exceeding the number of jobs (only when Cargo is in control of the job server). That would prevent it from accumulating multiple foo-sys(build) jobs doing nothing (it's pretty easy to have 3 or 4 of them with -j1).

@matthiaskrgr
Copy link
Member Author

It turned out that the problem of niceness and -j being ignored while bootstrapping rustc only appears when I use sccache as as rustc_wrapper, hmm.

@alexcrichton
Copy link
Member

I agree that part of this is definitely a bug in the cc crate itself, where cc should never drop its own implicit token. I would also agree though that if you're using sccache that can also mess with things because the jobserver file descriptors aren't inherited to the actual rustc instance so if rustc spawns parallel work it won't be rate-limited.

@tgnottingham
Copy link

I believe this issue also leads to misleading cargo build --timings output. I've created an issue for cc -- rust-lang/cc-rs#858. I'm unsure if any cargo work is needed on top of that.

@epage epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-jobserver Area: jobserver, concurrency, parallelism C-bug Category: bug S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

5 participants