Introduce 'nice' value under cargo.toml -> [build]

[ShadowJonathan]

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.

[Eh2406]

cc #9221

[ShadowJonathan]

(i should note that jobs != absolute CPU usage, because of kernel scheduling and multi-threaded compilation and such, nice in this case then actually allows a good prioritization configuration value)

[pgray]

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]

You could also try schedtool -B -e cargo <args> or schedtool -I -e cargo <args> for the BATCH and IDLE scheduling policies, depending on how much you want them deprioritized.

[soloturn]

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]

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]

FWIW, OOM killed issue is tracked in #9157, as there might be other specific approaches for it.

[pcgeek86]

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-micro virtual machine in Google Cloud Platform (GCP). I installed the Rust toolchain on it. Then I tried to install stu with cargo 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.