~5 Minutes Of Coding Yields A 6%+ Boost To Linux I/O Performance

[LtdJorge]

At the time of this writing, on my Debian sid amd64:

# apt-cache search io_uring
liburing-dev - Linux kernel io_uring access library - development files
liburing2 - Linux kernel io_uring access library - shared library
librust-blocking-dev - thread pool for isolating blocking I/O - Rust source code
librust-io-uring-dev - Low-level `io_uring` userspace interface for Rust - Rust source code

# apt-cache rdepends liburing2
liburing2
Reverse Depends:
libmariadbd19
samba-vfs-modules
qemu-utils
qemu-system-x86
qemu-system-sparc
qemu-system-ppc
qemu-system-misc
qemu-system-mips
qemu-system-common
qemu-system-arm
qemu-guest-agent
plocate
mpd
mariadb-test
mariadb-server-core
mariadb-backup
liburing-dev

Good to see that the (probably conditional, anyway) usage of io_uring hasn't spread to many packages yet.

From Gentoo:
app-containers/lxc-5.0.3
app-emulation/qemu-7.2.4
app-emulation/qemu-7.2.6
app-emulation/qemu-7.2.7
app-emulation/qemu-7.2.8
app-emulation/qemu-8.0.4
app-emulation/qemu-8.0.5
app-emulation/qemu-8.1.2
app-emulation/qemu-8.1.3
app-emulation/qemu-8.1.4
app-emulation/qemu-8.2.0
app-emulation/qemu-9999
dev-cpp/folly-2023.06.19.00
dev-db/mariadb-10.11.5
dev-db/mariadb-10.11.5-r1
dev-db/mariadb-10.6.14
dev-db/mariadb-10.6.15
dev-db/mariadb-10.6.15-r1
dev-libs/libdex-0.2.0
dev-libs/libdex-0.4.0
dev-libs/libdex-0.4.1
dev-libs/rocksdb-6.29.5
dev-libs/rocksdb-7.9.2
dev-libs/rocksdb-7.9.2-r1
dev-libs/rocksdb-8.6.7
dev-libs/rocksdb-8.9.1
dev-ruby/io-event-1.2.2
dev-ruby/io-event-1.3.2
dev-ruby/io-event-1.3.3
dev-ruby/io-event-1.4.0
games-board/jja-0.7.1
games-board/jja-0.8.0
games-board/jja-0.8.1
games-board/jja-0.9.0
games-board/jja-9999
media-sound/mpd-0.23.12-r2
media-sound/mpd-0.23.13
net-fs/samba-4.18.4-r1
net-fs/samba-4.18.5-r1
net-fs/samba-4.18.6-r1
net-fs/samba-4.18.7
net-fs/samba-4.18.8
net-fs/samba-4.18.9
net-fs/samba-4.19.0-r1
net-fs/samba-4.19.1
net-fs/samba-4.19.2
net-fs/samba-4.19.3
sci-physics/root-6.28.10-r1
sci-physics/root-6.30.02-r1
sci-physics/root-6.30.9999
sci-physics/root-9999
sys-apps/plocate-1.1.19
sys-apps/plocate-1.1.20
sys-block/fio-3.27-r4
sys-block/fio-3.30-r1
sys-block/fio-3.34
sys-cluster/ceph-16.2.14-r1
sys-cluster/ceph-17.2.6-r8
sys-cluster/ceph-17.2.7
sys-cluster/ceph-18.2.0-r2
sys-cluster/glusterfs-10.4
sys-cluster/glusterfs-10.5
sys-cluster/glusterfs-11.0-r2
sys-cluster/glusterfs-11.1

And that's only packages on the main ebuild repo, and using liburing which is the high level library to the kernel io_uring.

[coder]

Mostly reads, but still some writes, and the needed locks.

Locks aren't generally expensive, unless you've got multiple readers/writers contending for them. Then, your problem is this contention, rather than the locks themselves.

True. However a CoW-filesystem and alike can make this take more time.

You shouldn't be using CoW for databases. That's basically a textbook example of when to disable it. Many distros automatically disable BTRFS' CoW, in the default directories where DBs like PostgreSQL and MySQL store their database files.

Why stacktrace? Better set perf to record the pid of kodi and initiate a shutdown. That will get you information on what it wastes time on.

Stack trace will tell you which threads are blocking on what. I'll admit it's somewhat crude. Perhaps there's a better thread debugging tool which also figures out which threads own which mutexes, so you can quickly & easily see the blocking relationships between the threads.

[coder]

...
dev-libs/libdex-0.4.1
...

Some of these packages are libraries & other packages you listed might contain (public) libraries. Therefore, you'd really want to create a full tree of everything that indirectly depends on liburing to know the full extent of its possible usage.