Re: [RFC PATCH 2/2] io_uring: fix io may accumulation in poll mode

[Jens Axboe <axboe@kernel.dk>]

On 12/10/25 1:55 AM, Fengnan Chang wrote:
> In the io_do_iopoll function, when the poll loop of iopoll_list ends, it
> is considered that the current req is the actual completed request.
> This may be reasonable for multi-queue ctx, but is problematic for
> single-queue ctx because the current request may not be done when the
> poll gets to the result. In this case, the completed io needs to wait
> for the first io on the chain to complete before notifying the user,
> which may cause io accumulation in the list.
> Our modification plan is as follows: change io_wq_work_list to normal
> list so that the iopoll_list list in it can be removed and put into the
> comp_reqs list when the request is completed. This way each io is
> handled independently and all gets processed in time.
> 
> After modification,  test with:
> 
> ./t/io_uring -p1 -d128 -b4096 -s32 -c32 -F1 -B1 -R1 -X1 -n1 -P1
> /dev/nvme6n1
> 
> base IOPS is 725K,  patch IOPS is 782K.
> 
> ./t/io_uring -p1 -d128 -b4096 -s32 -c1 -F1 -B1 -R1 -X1 -n1 -P1
> /dev/nvme6n1
> 
> Base IOPS is 880k, patch IOPS is 895K.

A few notes on this:

1) Manipulating the list in io_complete_rw_iopoll() I don't think is
   necessarily safe. Yes generally this is invoked from the
   owning/polling task, but that's not guaranteed.

2) The patch doesn't apply to the current tree, must be an older
   version?

3) When hand-applied, it still throws a compile warning about an unused
   variable. Please don't send untested stuff...

4) Don't just blatantly bloat the io_kiocb. When you change from a
   singly to a doubly linked list, you're growing the io_kiocb size. You
   should be able to use a union with struct io_task_work for example.
   That's already 16b in size - win/win as you don't need to slow down
   the cache management as that can keep using the linkage it currently
   is using, and you're not bloating the io_kiocb.

5) The already mentioned point about the cache free list now being
   doubly linked. This is generally a _bad_ idea as removing and adding
   entries now need to touch other entries too. That's not very cache
   friendly.

#1 is kind of the big one, as it means you'll need to re-think how you
do this. I do agree that the current approach isn't necessarily ideal as
we don't process completions as quickly as we could, so I think there's
merrit in continuing this work.

-- 
Jens Axboe