Rewriting the GNU Coreutils in Rust [LWN.net]

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 10:18 UTC (Wed) by mathstuf (subscriber, #69389)
In reply to: Rewriting the GNU Coreutils in Rust by eru
Parent article: Rewriting the GNU Coreutils in Rust

True, but can't the utility also increase its CPU nice value while keeping the I/O niceness low to reflect that the parallelism is mainly about I/O than CPU utilization?

to post comments

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 10:31 UTC (Wed) by matthias (subscriber, #94967) [Link] (1 responses)

Why should a utility that is I/O-bound and only uses minimal CPU time increase the CPU nice value? Such a utility should have a low CPU-nice value such that in case it needs the CPU (for a very short time) to issue the next IO operation it can do so and make the most efficient use of the available IO bandwidth. For other tasks it should not matter whether the few msec of CPU time needed are nice or non-nice, but for the utility it certainly matters whether it has to wait for the CPU or not.

And of course, high nice values are for background tasks where the user is not waiting for the output. If I run a core utility from the shell, I want to have the result now and I do not care whether a background task has to wait.

Rewriting the GNU Coreutils in Rust

Posted Jun 20, 2021 14:35 UTC (Sun) by roblucid (guest, #48964) [Link]

I suppose as it's a long running non-interactive command it's just giving interactive tasks first crack at the CPU.
If there's multiple io commands in flight, waiting a little to process one of them won't hurt.