|
|
Log in / Subscribe / Register

Rewriting the GNU Coreutils in Rust

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 8:06 UTC (Wed) by Sesse (subscriber, #53779)
In reply to: Rewriting the GNU Coreutils in Rust by warrax
Parent article: Rewriting the GNU Coreutils in Rust

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


to post comments

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. :)


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