Re: [PATCH 4/6] io_uring: let fast poll support multishot

[Hao Xu <haoxu@linux.alibaba.com>]

在 2021/9/7 上午3:09, Pavel Begunkov 写道:
> On 9/6/21 6:40 PM, Hao Xu wrote:
>> 在 2021/9/6 下午11:56, Pavel Begunkov 写道:
>>> On 9/3/21 12:00 PM, Hao Xu wrote:
>>>> For operations like accept, multishot is a useful feature, since we can
>>>> reduce a number of accept sqe. Let's integrate it to fast poll, it may
>>>> be good for other operations in the future.
>>>
>>> __io_arm_poll_handler()         |
>>>     -> vfs_poll()                 |
>>>                                   | io_async_task_func() // post CQE
>>>                                   | ...
>>>                                   | do_apoll_rewait();
>>>     -> continues after vfs_poll(),|
>>>        removing poll->head of     |
>>>        the second poll attempt.
         this(removal) only happen when there is error or it is
EPOLLONESHOT
    |
>>>
>>>
>> Sorry.. a little bit confused by this case, would you mind explain a bit
>> more..is the right part a system-workqueue context? and is
>> do_apoll_rewait() io_poll_rewait() function?
> 
> I meant in a broad sense. If your patches make lifetime of an accept
> request to be like:
> 
> accept() -> arm_apoll() -> apoll_func() -> accept() -> ...
>      -> ... (repeat many times)
> 
> then do_apoll_rewait() is the second accept in the scheme.
> 
> If not, and it's
> 
> accept() -> arm_poll() -> apoll_func() -> apoll_func() ->
>   ... -> ?
> 
> Then that "do_apoll_rewait()" should have been second and
> other apoll_func()s.
> 
> So, it's rather a thing to look after, but not a particular
> bug.
> 
> 
>>> One of the reasons for forbidding multiple apoll's is that it
>>> might be racy. I haven't looked into this implementation, but
>>> we should check if there will be problems from that.
>>>
>>> FWIW, putting aside this patchset, the poll/apoll is not in
>>> the best shape and can use some refactoring.
>>>
>>>
> [...]
>