search

rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.66k stars 2.41k forks source link

Be `ionice` on unix #5569

Open richard-uk1 opened 6 years ago

richard-uk1 commented 6 years ago

When building on unix, I don't think there would be any harm setting the i/o nice value, and it may improve UX in some circumstances. From rustc-perf#232.

Edit The original post meant specifically the i/o scheduling nice, not the general process nice.

richard-uk1 commented 6 years ago

I'm happy to implement this, just want to see if there were any reasons it isn't a good idea first.

alexcrichton commented 6 years ago

I don't think that we'll want this to be the default because it runs the risk of making builds slower by default, but having it as a configuration option seems reasonable

lukaslueg commented 6 years ago

This should at least be behind a config-option so the default behavior remains the expected behavior, which is niceness 0. At least on Linux, you are always able to automatically move cargo into its own control group and set its CPU-, RAM-, and IO-priority. Sure it's more complicated and not built-in, yet there is a strong case to be made that cargo is first and foremost a process like any other; and the cgroup-solution is strictly more powerful & beyond reach by cargo.

matklad commented 6 years ago

At least on Linux, you are always able to automatically move cargo into its own control group and set its CPU-, RAM-, and IO-priorit

Interesting! Perhaps we should add instructions of how to do that to Cargo docs? I feel that "I run cargo build on my dev laptop while also using a browser and IDE" is a common use-case, so many people might want to reduce Cargo's priority, even if they don't realize that it is possible.

richard-uk1 commented 6 years ago

Yeah I think documentation may be the best way to go here.

On Tue, May 29, 2018 at 12:32 PM, Aleksey Kladov notifications@github.com wrote:

At least on Linux, you are always able to automatically move cargo into its own control group and set its CPU-, RAM-, and IO-priorit

Interesting! Perhaps we should add instructions of how to do that to Cargo docs? I feel that "I run cargo build on my dev laptop while also using a browser and IDE" is a common use-case, so many people might want to reduce Cargo's priority, even if they don't realize that it is possible.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rust-lang/cargo/issues/5569#issuecomment-392744493, or mute the thread https://github.com/notifications/unsubscribe-auth/ABU-XkYWCyvf_z-UJHOIjokB9_YZ365xks5t3THEgaJpZM4UN_KU .

lukaslueg commented 6 years ago

@matklad, let me actually check on it. There once was a control-groups management daemon which by now seems to have been replaced by systemd, which itself lacks the feature.

hammerandtongs commented 6 years ago

@derekdreery

I'm the linked post from that thread.

Just to be clear I said IONICE

"""ionice - set or get process I/O scheduling class and priority"""

This is much more effective for me with less negative impact on the build.

Linux desktop io scheduling needs a bit more help then process scheduling but ymmv.

richard-uk1 commented 6 years ago

@hammerandtongs Updated.

lukaslueg commented 5 years ago

I've looked into this again and it seems that the daemon to place processes into control groups automatically has been deprecated without being replaced. The way to go seems to be using systemd-run to create a transient, resource-constrained scope and spawn cargo within. For example

systemd-run --scope --slice=user.slice -p IOAccounting=true -p IOAccounting=true -p CPUWeight=1 -p IOWeight=1 cargo test

This creates a new scope under user.slice with minimal IO- and CPU-weights. That is, the user-1000-slice (or whatever your "real" users runs under) and all its processes will completely dominate the cargo-process for resources.

Relevant documentation for systemd-run and systemd.resource-control.