Rewriting the GNU Coreutils in Rust [LWN.net]

Rewriting the GNU Coreutils in Rust

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

> remember that switching thread is not cheap at all

This isn't really true in this day and age. It used to be quite expensive, but that's no longer the case (in the common case). Of course it's still more expensive than not doing it (assuming that you cannot do anything productive with that parallelism), but that's neither here nor there.

Anyway, the point of io_uring is avoiding traversing the userland<->kernel boundary unless absolutely required because *THAT* is expensive.

More generally, I'd also challenge your assertion that accessing the hardware in a multithreaded fashion doesn't have gains. Sure, it might not do much for spinning rust, but SSDs can certainly handle multiple non-interfering I/O operations.

to post comments

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 7:21 UTC (Wed) by warrax (subscriber, #103205) [Link] (2 responses)

(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.

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.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 8:06 UTC (Wed) by Sesse (subscriber, #53779) [Link] (1 responses)

> Anyway, the point of io_uring is avoiding traversing the userland<->kernel boundary unless absolutely required because *THAT* is expensive.

That is certainly a part of the point, but not the entire point. Probably more important than that is to be able to do issue many I/Os in parallel, ie., it finally gives Linux usable, performant async I/O. This is required if you want to drive modern SSDs fast, but also for many small files on a HDD. When I implemented io_uring support in plocate, that was the big killer; being able to issue 256 stat()s at once and watch the kernel reorder them into one big head sweep, as opposed to jittering back and forth over the disk. (You'll see a similar thing when ls-ing or cp-ing many (small) files.) Syscall overhead didn't play into it at all; in fact, nearly all the gains were realized in the prototype implementation where I called io_uring_enter() once for every stat, ie., no reduction in syscall overhead at all.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 22:59 UTC (Thu) by warrax (subscriber, #103205) [Link]

You're right. I was being a bit oblique I suppose... One of the advantages is the ability to avoid the syscall overhead of all of select(), epoll() etc. ... which means that it's a lot cheaper to just queue up IO. :)