Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Epoll vs. io_uring in Linux

sibexi.co

Post reply on HN
Print view View original

31–40 of 79 posts

Re: Epoll vs. io_uring in Linux

#31

Post by Asmod4n »

Uptrenda wrote: post #3

Yes, io_uring is significantly faster than epoll (I think I had like 20% faster req/s with io_uring.) The catch is that its kernel opt-in and disabled just about everywhere for security reasons. I think that it has direct memory sharing between the kernel and user-land which is kind of yikes. There's been multiple exploits that hit io_uring in recent times. It's because of this that even engineering projects that try…

The main reason why it gets disabled is fixed now, the latest RC got cBPF support and as such you can restrict what OPs can be run now instead of just fully disabling it.

Re: Epoll vs. io_uring in Linux

#32

Post by Asmod4n »

insanitybit wrote: post #21
csdreamer7 wrote: post #13

Earlier quoted context omitted.

RHEL 9 and 10 now fully support io_uring by default. It is very recent, but this covers a lot of corporate Linux installs. Gemini 'said' Ubuntu and SuSE support it as well, but did not provide any links to prove it. https://access.redhat.com/solutions/4723221 Go should reconsider support. They should have a 'go' at it.

It's still seccomp'd off in most environments because io-uring is still a seccomp bypass that doesn't play well with kernel security systems (audit subsystem), even if it weren't also like the #1 or #2 exploit vector for privesc.

That’s solved as of last week, you can use cBPF now to disable functionality.

Re: Epoll vs. io_uring in Linux

#33

Post by camkego »

toast0 wrote: post #28
Sibexico wrote: post #18

Earlier quoted context omitted.

Basically, v0 and v1 of the repo is completely different implementations, written almost from scratch. Now working on the 3rd one implementation, I believe the last one. :) Completely different architectural choices was made.

If it's still running on more than a single core, and your students want it to go faster, aligning the work to cpus will almost certainly be useful. I saw you mentioned windows development elsewhere. You might be interested to know that Microsoft pionered Receive Side Scaling and Send Side Scaling. If you try your proxy out on Windows, be sure to hook into those systems there. The less work your proxy does, the more…

Pin threads to cores, and make sure threads different cores aren’t writing to the same 64 or 128 byte block. Lookup “false sharing”

Re: Epoll vs. io_uring in Linux

#35

Post by thomashabets2 »

I've not yet tested the shared buffers for my io uring based web server, but that's because instead of reading from a file and writing, i send directly from a mmaped region.

But really, I want to sendfile with io_uring, but that's not supported yet.

My writeup, with extra buzzwords like Rust and kTLS: https://blog.habets.se/2025/04/io-uring-ktls-and-rust-for-ze...

It was on HN too: https://news.ycombinator.com/item?id=44980865

Re: Epoll vs. io_uring in Linux

#36

Post by ahepp »

toast0 wrote: post #11

> But my students weren’t as happy as I was - they wanted to build something genuinely useful, and they were really disappointed that our “product” had strong architectural limits and couldn’t outperform titans like nginx and haproxy. I took a (very brief) look at the github repo [1], it doesn't look like you're doing anything with cpu pinning. You can probably eke (thanks) out a bit more performance if you cpu pin y…

I would be interested to see benchmarks for that patch

Re: Epoll vs. io_uring in Linux

#37

Post by Chaosvex »

LoganDark wrote: post #22
mrlonglong wrote: post #2

Boost asio if you love C++ and asynchronous networking.

Boost is so inconvenient, they're huge dynamic libraries that are a pain to build and use. Even when I was already using CMake, getting Boost installed in a way where it could be discovered was super annoying. (I was on Mac, though)

Asio also comes in standalone form and both versions are header-only. Not necessarily directly related to your comment but adding it on, anyway.

Re: Epoll vs. io_uring in Linux

#38

Post by cherryteastain »

LoganDark wrote: post #22
mrlonglong wrote: post #2

Boost asio if you love C++ and asynchronous networking.

Boost is so inconvenient, they're huge dynamic libraries that are a pain to build and use. Even when I was already using CMake, getting Boost installed in a way where it could be discovered was super annoying. (I was on Mac, though)

You can statically link boost

Re: Epoll vs. io_uring in Linux

#39

Post by Ne02ptzero »

thomashabets2 wrote: post #35

I've not yet tested the shared buffers for my io uring based web server, but that's because instead of reading from a file and writing, i send directly from a mmaped region. But really, I want to sendfile with io_uring, but that's not supported yet. My writeup, with extra buzzwords like Rust and kTLS: https://blog.habets.se/2025/04/io-uring-ktls-and-rust-for-ze... It was on HN too: https://news.ycombinator.com/item?i…

FYI you can use sendfile ish with uring, since splice(2) is implemented. Not as user friendly as sendfile, but should work fairly similarly.

Re: Epoll vs. io_uring in Linux

#40

Post by FooBarWidget »

vlovich123 wrote: post #5
MathMonkeyMan wrote: post #4

Earlier quoted context omitted.

I switched out asio's epoll backend for its io_uring in a database server and CPU utilization shot up. Probably depends on usage and the specifics of how it's integrated into the event code.

That’s paradoxically what you can expect on a busy server - your CPU can spend time doing work that would have been previously IO wait time. Of course, it could be a bug in the implementation where you’re spinning doing no work erroneously, but depends on the details.

This makes no sense. Epoll is already non-blocking, you never waste time waiting for I/O as long as there is work to do. Io_uring only boosts CPU efficiency (batching of syscalls, for example), it does not reduce blocking.
Post reply on HN