Hacker News Reader

Hacker News

Comment by SPascareli13 | Hacker News Reader

Full thread

SPascareli13

So, is io_uring used anywhere yet?

View on HN

I’m using it for all I/O (file, socket, SPI and UART) in an embedded application written in Swift. Wrappers here:

https://github.com/PADL/IORingSwift

What type of app can afford to run on Linux (not bare metal) but still needs such low level performance optimizations?

Lowering CPU usage can save battery. Just because you are running Linux doesn't mean you don't have a power budget.

Among many other projects I touched, we had a database engine which planned to move to io_uring as soon as it could be made available (it wasn't distributed outside company, so it was a question of internal infrastructure)

PREEMPT_RT also includes a lot of possible low-latency work.

io_uring also provides ridiculous performance benefits for normal server code, too.

Context switches are expensive. Often more expensive than operating on the data. io_uring providews a major reduction, or even near elimination of context swithes for io. It provides big win in a lot of server contexts in terms of packets/iops/throughput.

Initial motivation was lack of non-blocking SPI I/O in Linux user space. Then it made sense to use it for everything, it’s a straightforward mapping to Swift’s structured concurrency, so why not?

Anything using glommio [1].

[1] https://crates.io/crates/glommio/reverse_dependencies

libblkio, used by qemu for some block storage, uses it. Independently, qemu also uses io_uring for some Linux file operations.

My experience with io_uring is that it requires a fairly fundamental change in the way you architect software, which makes it hard to retrofit it to existing code (eg. code using poll). If you have a greenfield project that requires very high performance and will only/mainly run on Linux then you should strongly consider it. I'd actually love to hear peoples' thoughts on whether there is a good way to retrofit code.

I think there's still a lot of concerns related to security https://www.phoronix.com/news/Google-Restricting-IO_uring

Were any of this vulnerabilities disclosed? I saw that Google blocked it in some places, but without fully understanding what are these vulnerabilities it's hard to make a good judgement on whether it is usable or not in some application.

There are practical backward compatibility and security issues currently that prevent widespread deployment. I’ve been leaning into io_uring going forward because it is clearly the future and brings a lot to the table. It still can’t be used in many environments but I expect it to be mainstream in 2-3 years. Niche, but not for much longer.

Most software doesn’t properly use the old io_submit facility and that has been around for decades, despite the large performance improvements possible. Even when io_uring is widely deployable, most software won’t use it.

What are the open security issues?

This only applies to Linux distro packages though right? Servers, embedded, mobile, etc only target specific kernels and so can avoid the backwards compatibility issues and in many cases have all of thr latest security patches.

Yes.

But sometimes it means that what you have is software that can't run on recent enough kernel to have io_uring (^_^;;)

The old aio API is very inefficient and has awful quirks, such as not working on regular files opened without O_DIRECT. Not surprised no one used it

Am I wrong? Just noticed the downvote. That is my understanding of the old AIO kernel API anyway. The original io_uring paper describes some of the deficiencies of AIO. And the fact that the API is broken on non-O_DIRECT regular file descriptions is well known.

You're not wrong.

I used it for some high datarate record applications at work.

Does the job nicely without even half the boilerplate of aio if you use liburing.

My team uses it as part of a high performance storage system at work (but only for disk IO).

Reply on news.ycombinator.com