|
|
Log in / Subscribe / Register

Rewriting the GNU Coreutils in Rust

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 7:21 UTC (Wed) by warrax (subscriber, #103205)
In reply to: Rewriting the GNU Coreutils in Rust by warrax
Parent article: Rewriting the GNU Coreutils in Rust

(Apologies for the self-reply.)

Note also that parallelizing I/O can actually also help with the latency incurred between userland and the actual device latency. The more commands you can queue ahead of time, the more commands the device can go through in a rapid fire fashion -- even in the case where no actual parallel fetching/writing can happen on the device itself.


to post comments

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 16:24 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

And if you scattergun 10 requests at one hdd, the kernel tries to re-order them to minimise the overall time - it should spot if two are close together, and read them one after the other in the right order, etc etc.

Cheers,
Wol

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 14:55 UTC (Thu) by farnz (subscriber, #17727) [Link]

Not just the kernel - all modern storage devices also reorder requests to minimise the overall time.

Every level in the stack below the application benefits from having deep queues; the only reason to not issue all the I/O you can at once is that you might not be able to handle the responses as fast as they come in. Otherwise, you might as well queue up as much I/O as you can keep track of; the kernel will do its re-ordering, and the device can reorder anything from 31 commands upwards to maximise throughput.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds