Be ionice on unix

[richard-uk1]

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]

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

[alexcrichton]

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]

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]

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]

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

…

On Tue, May 29, 2018 at 12:32 PM, Aleksey Kladov ***@***.***> 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 <#5569 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABU-XkYWCyvf_z-UJHOIjokB9_YZ365xks5t3THEgaJpZM4UN_KU> .

[lukaslueg]

@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]

@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]

@hammerandtongs Updated.

[lukaslueg]

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.