Every system call incurs the following overhead: switching from user mode to kernel mode, saving state, and checking parameters. For a server processing hundreds of thousands of operations per second, that overhead adds up to a significant amount.
Two shared gaskets
io_uring creates two circular queues in a memory region accessible to both the program and the kernel:
- Incoming Items — the program records requests here
- Received Data — the program records the return results here
A program can queue dozens of operations and then notify the kernel just once. In polled kernel mode, no system calls are even needed—the kernel detects new requests on its own.
How is this different from the previous methods?
epoll The indicator lets you know when the file is ready, but you still have to call it yourself read. It’s asynchronous during the wait phase but synchronous during the execution phase. io_uring is asynchronous in both phases: you send a read request and receive the result when it’s done.
It’s not limited to sockets either. Regular file reads and writes, opening files, renaming files, and even many dependent sequential operations are all supported.
The Price
The attack surface is larger, and historically, a series of vulnerabilities has led some vendors to restrict io_uring in shared multi-user environments. The programming model is also more complex: managing the buffer lifecycle during in-flight operations is a common source of errors.
If your application isn't limited by the number of system calls, io_uring adds nothing but complexity. Measure first.
Thảo luận