# io\_uring Published articles for io\_uring. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Linux's IO\_uring Sees Some "Crazy" Patches That Deliver Very Nice Improvements DevFeed: [Linux's IO\_uring Sees Some "Crazy" Patches That Deliver Very Nice Improvements]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-11T16:21:33Z Content type: news Language: en Sources: [Phoronix]() Topics: [io\_uring](), [Linux](), [IO]() Tags: [desktop-linux](), [developer](), [io](), [io-uring](), [kernel](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [ubuntu-benchmarks](), [ubuntu-hardware]() ### AI overview Linux io_uring patches proposed by Jens Axboe aim to improve blocking behavior and reduce unnecessary thread wakeups, context switches, and task-work completion overhead. Requests would run inline in blocking mode and offload only when they actually block, while preserving the submitting task's user-visible identity. ### Source excerpt Linux block subsystem maintainer and IO_uring lead developer Jens Axboe continues to uncover new opportunities for making the wonderful IO_uring framework even more performant within the Linux kernel. For ending out the week he's posted some "crazy" patches delivering some significant gains... ## Offloading I/O to Dedicated Cores: An Asymmetric io\_uring Backend for Seastar and ScyllaDB DevFeed: [Offloading I/O to Dedicated Cores: An Asymmetric io\_uring Backend for Seastar and ScyllaDB]() Original publisher: [Read original article]() Author: Cynthia Dunlop Published: 2026-07-22T18:03:10Z Content type: article Language: en Sources: [ScyllaDB]() Topics: [IO](), [io\_uring](), [Architecture & Design](), [C++](), [distributed-systems](), [Linux](), [networking](), [Latency]() Tags: [aio](), [architecture](), [c-plus-plus](), [cpu](), [design](), [engineering](), [i](), [io-uring](), [latency](), [linux](), [networking](), [performance](), [seastar](), [systems]() ### AI overview This article presents Seastar's asymmetric io_uring backend, which moves low-level I/O work from application cores to dedicated cores. It explains the shared-nothing architecture, the motivations for offloading I/O, the design trade-offs, and the comparison with Seastar's existing linux-aio backend. ### Source excerpt We moved low-level I/O execution off application cores to dedicated networking cores using Seastar's new asymmetric_io_uring backend. Explore the architecture design, trade-offs, and benchmark results. ## Announcing Silk: a silky smooth fiber runtime for ClickHouse DevFeed: [Announcing Silk: a silky smooth fiber runtime for ClickHouse]() Original publisher: [Read original article]() Author: James Cunningham; Vadim Skipin Published: 2026-06-25T19:37:21Z Content type: release Language: en Sources: [ClickHouse Blog]() Topics: [C++](), [networking]() Tags: [c-plus-plus](), [clickhouse](), [concurrency](), [cpu](), [distributed-systems](), [io-uring](), [latency](), [open-source]() ### AI overview Silk is a new open-source C++ stackful-fiber runtime for ClickHouse. It combines NUMA-aware work stealing, io_uring-based I/O, and no steady-state heap allocation to support high-concurrency networking and file I/O. ### Source excerpt Silk is a new open-source C++ fiber runtime built for ClickHouse, combining a NUMA-aware work-stealing scheduler, io_uring I/O, and zero heap allocation in the steady state to deliver nanosecond-level fiber yields and dramatically lower tail latency for h ## QEMU version 10.2.0 released DevFeed: [QEMU version 10.2.0 released]() Original publisher: [Read original article]() Published: 2025-12-24T23:12:00Z Content type: release Language: en Sources: [QEMU]() Topics: [qemu](), [version](), [Availability](), [io\_uring](), [Arm](), [RISC-V](), [migration](), [virtio]() Tags: [announce](), [arm](), [availability](), [bugs](), [changelog](), [ci](), [documentation](), [features](), [google](), [improvements](), [io-uring](), [migration](), [performance](), [qemu](), [qemu-10-2](), [release](), [releases](), [risc-v](), [testing](), [virtio]() ### AI overview QEMU 10.2.0 has been released, with over 2,300 commits from 188 authors. Highlights include FreeBSD 9pfs support, live VM updates through cpr-exec migration, io_uring performance improvements, expanded ARM and RISC-V emulation, and additional fixes and device support. ### Source excerpt We'd like to announce the availability of the QEMU 10.2.0 release. This release contains 2300+ commits from 188 authors. ## How io\_uring improves database performance DevFeed: [How io\_uring improves database performance]() Original publisher: [Read original article]() Published: 2025-12-11T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [io\_uring](), [Databases](), [Linux Kernel](), [NVMe]() Tags: [asynchronous](), [database-performance](), [io](), [io-uring](), [nvme](), [performance]() ### AI overview This article explains how io_uring improves database performance through shared submission and completion queues, batching, fewer system calls, zero-copy operation, and features such as SQPoll and registered buffers. It also discusses DMA and the relevance of fast NVMe storage. ### Source excerpt . [How io_uring Improves Database Performance](how-iouring-improves-database-performance-cover... ## Postgres 18 Beta 1 Introduces Asynchronous I/O and Upgrade and Observability Changes DevFeed: [Postgres 18 Beta 1 Introduces Asynchronous I/O and Upgrade and Observability Changes]() Original publisher: [Read original article]() Author: Heikki Linnakangas Published: 2025-05-08T21:17:13Z Content type: release Language: en Sources: [Blog -- Neon Docs]() Topics: [releases](), [Release notes](), [io\_uring](), [observability](), [Linux](), [Statistics]() Tags: [asynchronous](), [io-uring](), [linux](), [observability](), [performance](), [postgres](), [release](), [release-notes](), [statistics]() ### AI overview Neon contributors describe the Postgres 18 Beta 1 release, highlighting its new asynchronous I/O subsystem, selectable I/O methods including io_uring, retained planner statistics during pg_upgrade, new upgrade options, and observability changes. ### Source excerpt Postgres 18 Beta 1 just shipped. As with previous major releases, this beta includes previews of all features planned for general availability. Read the release notes for the full list of updates, but we're gonna go through some highlights on this post. New in Postgres 18 Asynchr... ## Node.js 20.11.1 (LTS) DevFeed: [Node.js 20.11.1 (LTS)]() Original publisher: [Read original article]() Published: 2024-02-14T17:35:59Z Content type: release Language: en Sources: [Node.js Blog]() Topics: [Node.js]() Tags: [attacks](), [http](), [io-uring](), [linux](), [node-js](), [release](), [security](), [update]() ### AI overview Node.js 20.11.1 LTS is a security release that addresses multiple high- and medium-severity vulnerabilities, including code injection, privilege escalation, denial of service, path traversal, and permission-model bypasses. It also updates dependencies including undici, libuv, and OpenSSL. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. ## What Every Programmer Should Know About SSDs DevFeed: [What Every Programmer Should Know About SSDs]() Original publisher: [Read original article]() Author: Viktor Leis (noreply@blogger.com) Published: 2021-06-18T11:52:00Z Content type: article Language: en Sources: [Database Architects]() Topics: [Hardware](), [IO](), [Latency](), [Filesystems](), [io\_uring]() Tags: [asynchronous](), [hardware](), [io](), [io-uring](), [parallelism](), [performance](), [ssd](), [storage]() ### AI overview This article explains how NAND-flash SSDs differ from magnetic disks and how those differences affect software performance. It covers lower random-read latency, internal parallelism, concurrent I/O, and the effect of volatile write caching on observed write latency. ### Source excerpt Solid-State Drives (SSDs) based on flash have largely replaced magnetic disks as the standard storage medium. From the perspective of a programmer, SSDs and disks look very similar: both are persistent, enable page-based (e.g., 4KB) access through file systems and system calls, and have large capacities. However, there are also important differences, which become important if one wants to achieve optimal SSD performance. As we will see, SSDs are more complicated and their performance behavior can appear quite mysterious if one simply thinks of them as fast disks. The goal of this post is to provide an understanding of why SSDs behave the way they do, which can help creating software that is capable of exploiting them. (Note that I discuss NAND flash, not Intel Optane memory, which has different characteristics.) Drives not Disks SSDs are often referred to as disks, but this is misleading as they store data on semiconductors instead of a mechanical disk. To read or write from a random block, a disk has to mechanically move its head to the right location, which takes on the order of 10ms. A random read from an SSD, in contrast, takes about 100us - 100 times faster. This low read latency is the reason why booting from an SSD is so much faster than booting from a disk. Parallelism Another important difference between disks and SSDs is that disks have one disk head and perform well only for sequential accesses. SSDs, in contrast, consist of dozens or even hundreds of flash chips ("parallel units"), which can be accessed concurrently. SSDs transparently stripe larger files across the flash chips at page granularity, and a hardware prefetcher ensures that sequential scans exploit all available flash chips. However, at the flash level there is not much difference between sequential and random reads. Indeed, for most SSDs it is possible to achieve almost the full bandwidth with random page reads as well. To do this, one has to schedule hundreds of random IO requests concurre