HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
axboe
liburing
C2020–2026
axboe / liburing

liburing

Library providing helpers for the Linux kernel io_uring support

32Distinct people
41Mentions
0Explicit recommenders
3.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Library providing helpers for the Linux kernel io_uring support

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 11:34:28 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year41 dated mentions

Observed mentions: 2020-11-26 22:14:39 UTC to 2026-10-31 21:33:52 UTC.

02468102020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 8 mentions; 2 submissions, 6 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 4 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC909
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC615
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC826
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC541
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC716
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC505

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
liburing -------- This is the io_uring library, liburing. liburing provides helpers to setup and teardown io_uring instances, and also a simplified interface for applications that don't need (or want) to deal with the full kernel side implementation. For more info on io_uring, please see: https://kernel.dk/io_uring.pdf Subscribe to io-uring@vger.kernel.org for io_uring related discussions and development for both kernel and userspace. The list is archived here: https://lore.kernel.org/io-uring/ kernel version dependency -------------------------- liburing itself is not tied to any specific kernel release, and hence it's possible to use the newest liburing release even on older kernels (and vice versa). Newer features may only be available on more recent kernels, obviously. ulimit settings --------------- io_uring accounts memory it needs under the rlimit memlocked option, which can be quite low on some setups (64K). The default is usually enough for most use cases, but bigger rings or things like registered buffers deplete it quickly. root isn't under this restriction, but regular users are. Going into detail on how to bump the limit on various systems is beyond the scope of this little blurb, but check /etc/security/limits.conf for user specific settings, or /etc/systemd/user.conf and /etc/systemd/system.conf for systemd setups. This affects 5.11 and earlier, new kernels are less dependent on RLIMIT_MEMLOCK as it is only used for registering buffers. Regressions tests ----------------- The bulk of liburing is actually regression/unit tests for both liburing and the kernel io_uring support. Please note that this suite isn't expected to pass on older kernels, and may even crash or hang older kernels! Building liburing ----------------- # # Prepare build config (optional). # # --cc specifies the C compiler. # --cxx specifies the C++ compiler. # ./configure --cc=gcc --cxx=g++; # # Build liburing. # make -j$(nproc); # # Build liburing.pc # make liburing.pc # # Install liburing (headers, shared/static libs, and manpage). # sudo make install; See './configure --help' for more information about build config options. Out-of-source builds are also supported, keeping the source tree clean, and allowing you to have different configurations side-by-side: mkdir build && cd build ../configure make -j$(nproc) sudo make install FFI support ----------- By default, the build results in 4 lib files: 2 shared libs: liburing.so liburing-ffi.so 2 static libs: liburing.a liburing-ffi.a Languages and applications that can't use 'static inline' functions in liburing.h should use the FFI variants. liburing's main public interface lives in liburing.h as 'static inline' functions. Users wishing to consume liburing purely as a binary dependency should link against liburing-ffi. It contains definitions for every 'static inline' function. License ------- All software contained within this repo is dual licensed LGPL and MIT, see COPYING and LICENSE, except for a header coming from the kernel which is dual licensed GPL with a Linux-syscall-note exception and MIT, see COPYING.GPL and <https://spdx.org/licenses/Linux-syscall-note.html>. Jens Axboe 2022-05-19
Read the full README on GitHub

What Hacker News says

9 sources
I was unable to replicate these results, and neither can other people. I'll look into it again though and see. https://github.com/axboe/liburing/issues/189 edit: I'm not sure why I'm unable to reply to the comment below but I don't think anyone is being unnecessarily combative. I linked it twice because it is relevant to both replies to my comment. There is useful information in that thread if you read it end to end. What it does demonstrate is io_uring isn't a clear cut improvement over a much simpler approach. That may change in the future as it is improved though.
In Monoio – A thread-per-core Rust async runtime with io_uring
But if you read the thread, you realize he is testing on a 2011 laptop, and the older architecture may be causing the issues. He reported a 3x speedup running the benchmark on a Raspberry Pi 4 in the same thread[0] Someone claimed that you don't get to see the benefit of io_uring in a hypervisor[1], but they did not provide benchmark results. [0]: https://github.com/axboe/liburing/issues/189#issuecomment-94... [1]: https://github.com/axboe/liburing/issues/189#issuecomment-73...
In Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
Sure. https://github.com/axboe/liburing/issues/189 Original claims were in the 90% and above performance increase over epoll. Then issues were found, and the figure was adjusted to 60% over epoll. Then more issues were found, and now real-world performance tests are showing minimal speedups if any. Unfortunately the sibling commentors don't see "computer science" as a science but instead as a "feel good hobby", it seems. My point wasn't to hurt feelings, it was to provide a word of caution with these sorts of groundbreaking claims with respect specifically to the io_uring efforts, as they have been disingenuous quite a few times historically. I don't doubt Jens does fantastic work. I don't doubt that he's seen these speedups in very specific cases. But people are celebrating this as a win where they'd be skeptical of e.g. "breakthrough" t
Read the rest
reatments of cancer (footnote: in mice). It's the same thing.
In Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
I have found this comment on liburing[0] which clarifies some things for me. So is it because something like getaddrinfo is not just a simple operation, but a hodgepodge of stuff like "first try nscd, then read resolv.conf, then make a bunch of requests using one of many different protocols"? I think I have a lot more to learn about DNS... [0] https://github.com/axboe/liburing/issues/26#issuecomment-738... > [re: implementing getaddrinfo] It's not planned because it's not a single operation but a complex beast reading files, exchanging messages, etc. IMHO, as it's not a single operation it fundamentally doesn't fit liburing, but implementing under some framework on-top would be more viable.
In Understanding Rust futures by going way too deep
I dug up the thread with the benchmarks: https://github.com/axboe/liburing/issues/189 io_uring does win on more recent versions, but it's not like it blows epoll out of the water - it's an incremental improvement. Specifically for websockets where you have a lot of idle connections, you don't want a bunch of buffers waiting for reads for long periods of time - this is why Go doesn't perform well for websocket servers as calling Read() on a socket requires tying up both a buffer and a goroutine stack. I haven't looked into how registering buffers works with io_uring, if it's 1-to-1 mapping or if you can pass a pool of N buffers that can be used for reads on M sockets where M > N. The details matter for that specific case. Again where io_uring really shines is file IO because there are no good solutions there currently.
In Io_uring is not an event system
Has this problem been filed as an issue with Jens Axboe? I would like to hear his response to it. https://github.com/axboe/liburing I believe. > There's also alot of security implications To be clear, this is liburing, NOT the io_uring syscalls that I would assume Tokio would opt for. > io_uring is basically just a threaded work dispatcher Only under SQPOLL mode. This isn't an inherent property of io_uring. > All these process semantics are totally hidden and non-obvious Again, only if you use liburing. The syscalls make this abundantly clear, as there's no other way to program for them. > These known and unknown future pitfalls The problem isn't with io_uring here, the problem is with the over-saturation of the development world with people who do not care about doing things correctly or safely but instead quickly and cost-effectively. T
Read the rest
his is not unique to io_uring, however. Let's not throw the baby out with the bathwater. > And all the fanciest programming language type safety in the world won't save you. I agree whole-heartedly. > Expect several years of easy remote exploits down the road... I would rather be interested to see which sidechannels were attacked in order to take advantage of io_uring. Those vulns are going to lay with the framework implementors and the users of frameworks, less with io_uring. But I understand the concern.
In Tokio-Uring Design Proposal

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.