[PATCHSET 0/2] io_uring fixes

Jens Axboe posted 2 patches 6 days, 22 hours ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20260213143225.161043-1-axboe@kernel.dk
Maintainers: Stefan Hajnoczi <stefanha@redhat.com>, Fam Zheng <fam@euphon.net>
util/fdmon-io_uring.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
[PATCHSET 0/2] io_uring fixes
Posted by Jens Axboe 6 days, 22 hours ago
Hi,

Patch 1 here is the real meat of this, patch 2 is just a slight
improvement. For patch 1, it can literally yield a 50-80x improvement
on the io_uring side for idle systems, where ppoll() ends up sleeping
for 500 msec while there's IO to submit! I noticed this running the
io_uring regression tests in a vm, where I use a variety of block
devices for some of the tests. They would often randomly time out on
AHCI devices, while running them on a virtio-blk or nvme device would
finish in one second or so. I then wrote a reproducer to try and grok
this and had claude dive into this, which helped me better grasp the
various event loops.

Please take a look and tell me what you think. Some variant of patch 1
should definitely be considered, but let me know if this is the right
approach. I can easily test anything.

Also note - this seems to trigger more easily or consistently on
aarch64, which is where I run most of my local/immediate testing.

 util/fdmon-io_uring.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

-- 
Jens Axboe
Re: [PATCHSET 0/2] io_uring fixes
Posted by Fiona Ebner 2 days, 3 hours ago
Am 13.02.26 um 3:33 PM schrieb Jens Axboe:
> Hi,
> 
> Patch 1 here is the real meat of this, patch 2 is just a slight
> improvement. For patch 1, it can literally yield a 50-80x improvement
> on the io_uring side for idle systems, where ppoll() ends up sleeping
> for 500 msec while there's IO to submit! I noticed this running the
> io_uring regression tests in a vm, where I use a variety of block
> devices for some of the tests. They would often randomly time out on
> AHCI devices, while running them on a virtio-blk or nvme device would
> finish in one second or so. I then wrote a reproducer to try and grok
> this and had claude dive into this, which helped me better grasp the
> various event loops.
> 
> Please take a look and tell me what you think. Some variant of patch 1
> should definitely be considered, but let me know if this is the right
> approach. I can easily test anything.
> 
> Also note - this seems to trigger more easily or consistently on
> aarch64, which is where I run most of my local/immediate testing.
> 
>  util/fdmon-io_uring.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 

Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>