Repository navigation
Introduce 'nice' value under cargo.toml -> [build] #9250
Description
Describe the problem you are trying to solve
Often enough I have cargo builds running in the background, and then I open up some entertainment while it finishes, but I often notice that my desktop is generally slow (no surprise, something is hammering the CPU in the background). I've began doing nice -n 20 bash -c "cargo build" (or something similar) recently, however, I still sometimes forget it and get frustrated to cancel the build and restart it with the (pretty verbose) nice prefix.
Describe the solution you'd like
Add a string/int nice config parameter to cargo.toml, under [build].
If int: An absolute value cargo has to attempt to set the nice value to on compilation threads/processes.
If string: A "relative" value (-2, +5) to try to set to on compilation threads/processes.
This setting is ignored on targets which don't support nice-esc prioritisation (windows comes to mind), though maybe a generic priority config value could be introduced which attempts to do this across many operating systems.
If the nice value is less than the current value, and the current running-as user has no privilege to bump down the nice value, then it could/should be ignored with a warning printed to stderr or stdout.
Activity
Eh2406 commentedon Mar 10, 2021
cc #9221
ShadowJonathan commentedon Mar 10, 2021
(i should note that jobs != absolute CPU usage, because of kernel scheduling and multi-threaded compilation and such,
nicein this case then actually allows a good prioritization configuration value)pgray commentedon Jun 30, 2023
i'm looking for this exact functionality
i've tried aliases and bash functions but i think cargo supporting it directly would be... nice 😄
i'm surprised more build tools haven't added support as it results in a much more responsive experience in browsers/apps/etc. while compiling
the8472 commentedon Nov 4, 2023
You could also try
schedtool -B -e cargo <args>orschedtool -I -e cargo <args>for the BATCH and IDLE scheduling policies, depending on how much you want them deprioritized.soloturn commentedon Dec 30, 2023
pgray, "nice" is not part of a build tool, but outside. if you want nice experience, use "nice cargo ...". build tool does not need this complexity. in windoes this is not caled nice, but start /low or so. again nothing to do with cargo.
a way to go might be to control number of jobs, as suggested in #12912. but personally i am fan of using nice - as long it does not cause out of memory killer to terminate my browser for example.
melvyn2 commentedon Dec 30, 2023
IMO this would be more fitting for
.cargo/config.toml, rather than a crate's manifest - this build option doesn't really have anything to do with a specific crate.Also, limit job count/CPU usage doesn't fulfill the same use-case, as it doesn't adapt to other system loads. With a low priority, jobs can still use 100% CPU if no other processes need it, while dropping as low as needed when the user is doing something else mildly intensive.
weihanglo commentedon Dec 30, 2023
FWIW, OOM killed issue is tracked in #9157, as there might be other specific approaches for it.
pcgeek86 commentedon Oct 11, 2024
This is really important for lower-end systems that can get completely hung installing basic software.
Case in point:
I just spun up an
e2-microvirtual machine in Google Cloud Platform (GCP). I installed the Rust toolchain on it. Then I tried to installstuwithcargo install stu, which is an S3 storage Terminal UI (TUI) application. The VM eventually completely hung, and I lost my SSH session to it, because it's compiling dependencies.If Cargo were running as a lower priority Linux process, I probably would not lose connectivity to my remote servers.
the8472 commentedon Feb 11, 2025
Linux introduced a new mechanism somewhat similar to SCHED_BATCH. Threads/processes can now set their preferred time slice length. Latency sensitive tasks can set a small time slice, meaning they get scheduled earlier but also preempted earlier. Compute-bound tasks can set a larger timeslice, meaning they get to stay longer on the CPU, but get scheduled later after the lower-latency tasks.
I have run cargo under
perf sched record(and the performance cpu governor) and then looked atperf sched timehist
Which looks like rustc stays on-cpu for 100ms and more during compute-heavy phases, though it also experiences shorter timeslices, presumably when it's blocked by IO or mutexes.
So I maybe we could tell the kernel that cargo/rustc's preferred time-slice is something 50-100ms which should give it a bit of a penalty if there are other running tasks with the default
sched_runtime(3ms on my system).Though someone would have to test whether that helps interactive applications. If the system is bottlenecked on IO it probably wouldn't do much.