New Blocking-Avoidance Technique to Speed Up Linux IO_uring

A change that could bring major efficiency improvements has been proposed for IO_uring, Linux’s asynchronous I/O infrastructure. The proposer is Jens Axboe, maintainer of the Linux block layer and a central developer of IO_uring. On September 11, 2026, he published a series of small RFC patches to close out the week. Phoronix’s Michael Larabel covered the move in an article dated the same day, noting that Axboe himself described it as “crazy” on X. At this stage it remains a proposal for evaluation, and the timing for mainline adoption has not been confirmed.

The focus of this work is on how blocking behavior inside the kernel is handled. IO_uring has become established as a mechanism for fast asynchronous processing. However, for some operations no nonblocking path exists, and offloading to a separate context has always occurred. Axboe aims to reduce this offload cost so that overhead is incurred only when blocking actually happens. If adopted, the proposal is expected to benefit both latency and resource consumption.

Overview of the New Blocking-Avoidance Approach

The new approach is distinctive in that requests that might block are not handed to a separate worker from the start. Requests are executed directly in the caller’s context, and a fallback is used only when blocking actually occurs. Requests that do not block complete as-is, avoiding extra startup processing. Even when blocking does occur, it is not the request itself that is moved, but the identity of the execution agent. This idea is what differs most sharply from the conventional offload model.

Phoronix’s Michael Larabel reported that Axboe outlined the behavior in the RFC document. The original explanation is summarized in the following statement.

io_uring issues requests inline with IO_URING_F_NONBLOCK and punts to io-wq when that isn’t possible.

In other words, requests that can run without blocking are handled directly, while requests that cannot are punted to io-wq. The current approach prioritizes safety and unconditionally punts operations that have no nonblocking path. The new approach revisits this assumption and selects handling based on whether blocking occurs. Additional care has been taken to avoid failure even when the caller is deep inside the kernel.

How Nonblocking Execution and Offloading

Worked Until Now

IO_uring issues requests directly with IO_URING_F_NONBLOCK. When direct execution is not possible, processing is passed to workers of a work queue called io-wq. Operations such as fsync and statx, openat and the family of *at calls, extended attribute operations, fadvise, and splice have no nonblocking path. They were therefore unconditionally subject to offloading. Each offload involves thread startup, context switching, and a round trip of completion notification via task_work.

This cost can look small on a per-request basis. Under loads that process large numbers of requests, however, it accumulates to a non-negligible amount. Moreover, many of the affected operations often do not block in practice. Examples cited include cases where fdatasync completes without blocking and where statx hits the dentry cache. openat with O_TMPFILE is likewise highly likely to complete directly. Despite this, they have been uniformly offloaded for safety reasons.

IO_uring must prevent inadvertent blocking inside the kernel. Inadvertent blocking leads to reduced responsiveness and resource hold-up. Developers have therefore chosen a conservative design. Balancing safety and performance is the central challenge of this proposal. The new approach seeks to eliminate unnecessary offloading while maintaining safety.

The Idea of Swapping the Submitter and the

Execution Identity

Under the new approach, requests are issued directly in blocking mode even when they might block. If a request does not block, it simply completes, with no offload cost incurred. Only when a request actually blocks is the cost of the fallback paid. The challenge is that at the point blocking occurs, the submitter is deep inside the kernel and the request resides on the stack. In this state, the work itself cannot be moved to another thread.

The solution is to change what is moved, from the work to the identity. When the submitting task blocks, a waiting io-wq worker takes over the user-visible identity. This includes the thread ID, signal state, credentials, scheduling attributes, control group, and user accounting state. The worker that takes over completes the io_uring_enter call and returns to user space as the submitter. The original task completes the request as an io-wq worker and joins the resource pool.

From user space, it appears as if the same thread ID has returned from the system call. Internally, a different task_struct is returning the response. The design requires no awareness of this swap on the part of the user. Axboe also noted that a similar attempt existed about 20 years ago. It is in part a renewed challenge building on past knowledge.

Performance Gains and Current Outlook for

Mainline Adoption

Axboe described these patches as “crazy” on X. At the same time, he published a performance graph and called them “tasty results.” Phoronix’s Michael Larabel did not report the contents of the graph as detailed numbers. He characterized them as attractive results even for users with no interest in internal structure. Specific figures depend on measurements at the RFC stage and may vary by environment.

The timing for mainline adoption has not been confirmed. The Phoronix article raised whether it could make the Linux v7.4 cycle as a point to watch. An RFC is a stage intended to solicit comments, and the design needs refinement. Swapping identities touches sensitive state such as credentials and control groups. Safety verification and review are prerequisites for adoption.

Verification will require checking for race conditions and exception paths. Interactions with signal handling and privilege changes will also be subject to close scrutiny. The review will focus on achieving both performance gains and correctness. Input from the developer community and how it is reflected in the design will hold the key going forward. If adopted, heavy storage and logging workloads are expected to benefit greatly.

Connection to the Broader Kernel Speed-Up Trend

In kernel development, reducing unnecessary offloading and copying remains an ongoing challenge. IO_uring itself was introduced to reduce the number of system calls and enable efficient completion notification. This proposal lies on that same trajectory. It broadens the scope of nonblocking execution and shifts to a model where costs are incurred according to actual blocking. The direction of improving resource efficiency is consistent.

Similar optimizations are progressing in other areas. Linux Cache Aware Scheduling Expansion, MySQL Up to 360% Faster is an example where buffer settings and execution tuning pushed up application performance. The structure, in which a small behavioral change inside the kernel propagates across entire applications, is shared. Improvements to IO_uring could likewise affect a wide range of workloads, not just specific applications. The accumulation of base-level improvements is becoming increasingly important.

Faster storage devices form part of the background. Latency of non-volatile storage has shrunk, and software overhead has grown relatively larger. Per-offload costs are therefore more likely to determine overall performance. The difference becomes pronounced in highly parallel servers and logging infrastructure. This proposal can also be interpreted as a response to that structural change.

Editorial Opinion

On the short-term impact: over the next three to six months, review and testing of the RFC will take center stage. Because swapping identities touches privileges and control groups, review is expected to proceed cautiously. Reproduction of performance measurements and verification of exception paths will shape the discussion. At this stage, it is difficult to state a firm adoption timeline.

On the long-term view: over one to three years, it could influence the design philosophy of asynchronous infrastructure. Paying costs according to whether blocking occurs directly improves resource efficiency. It is expected to contribute to stable latency in storage processing and highly parallel servers. As a reconsideration of a past attempt, it is also worth recording.

Questions from the editors: should moving identities prioritize convenience or rigor? How far should an invisible swap be permitted from the user’s perspective? What conditions would allow both measured performance gains and safety verification? The community review process will determine the conclusion.

References

• “Linux’s IO_uring Sees Some “Crazy” Patches That Deliver Very Nice Improvements”, by Michael Larabel — Phoronix, 2026-09-11T16:21:33.000Z (ARR)
• Source URL: https://www.phoronix.com/news/Linux-IO-uring-Crazy-Friday