Re: IORING_OP_POLL_ADD slower than linux-aio IOCB_CMD_POLL

[Avi Kivity <avi@scylladb.com>]

On 15/06/2022 13.48, Pavel Begunkov wrote:
> On 6/15/22 11:12, Avi Kivity wrote:
>>
>> On 19/04/2022 20.14, Jens Axboe wrote:
>>> On 4/19/22 9:21 AM, Jens Axboe wrote:
>>>> On 4/19/22 6:31 AM, Jens Axboe wrote:
>>>>> On 4/19/22 6:21 AM, Avi Kivity wrote:
>>>>>> On 19/04/2022 15.04, Jens Axboe wrote:
>>>>>>> On 4/19/22 5:57 AM, Avi Kivity wrote:
>>>>>>>> On 19/04/2022 14.38, Jens Axboe wrote:
>>>>>>>>> On 4/19/22 5:07 AM, Avi Kivity wrote:
>>>>>>>>>> A simple webserver shows about 5% loss compared to linux-aio.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I expect the loss is due to an optimization that io_uring 
>>>>>>>>>> lacks -
>>>>>>>>>> inline completion vs workqueue completion:
>>>>>>>>> I don't think that's it, io_uring never punts to a workqueue for
>>>>>>>>> completions.
>>>>>>>> I measured this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>    Performance counter stats for 'system wide':
>>>>>>>>
>>>>>>>>            1,273,756 io_uring:io_uring_task_add
>>>>>>>>
>>>>>>>>         12.288597765 seconds time elapsed
>>>>>>>>
>>>>>>>> Which exactly matches with the number of requests sent. If 
>>>>>>>> that's the
>>>>>>>> wrong counter to measure, I'm happy to try again with the correct
>>>>>>>> counter.
>>>>>>> io_uring_task_add() isn't a workqueue, it's task_work. So that is
>>>>>>> expected.
>>>> Might actually be implicated. Not because it's a async worker, but
>>>> because I think we might be losing some affinity in this case. Looking
>>>> at traces, we're definitely bouncing between the poll completion side
>>>> and then execution the completion.
>>>>
>>>> Can you try this hack? It's against -git + for-5.19/io_uring. If 
>>>> you let
>>>> me know what base you prefer, I can do a version against that. I see
>>>> about a 3% win with io_uring with this, and was slower before against
>>>> linux-aio as you saw as well.
>>> Another thing to try - get rid of the IPI for TWA_SIGNAL, which I
>>> believe may be the underlying cause of it.
>>>
>>
>> Resurrecting an old thread. I have a question about timeliness of 
>> completions. Let's assume a request has completed. From the patch, it 
>> appears that io_uring will only guarantee that a completion appears 
>> on the completion ring if the thread has entered kernel mode since 
>> the completion happened. So user-space polling of the completion ring 
>> can cause unbounded delays.
>
> Right, but polling the CQ is a bad pattern, io_uring_{wait,peek}_cqe/etc.
> will do the polling vs syscalling dance for you.


Can you be more explicit?


I don't think peek is enough. If there is a cqe pending, it will return 
it, but will not cause compeleted-but-unqueued events to generate 
completions.


And wait won't enter the kernel if a cqe is pending, IIUC.


>
> For larger audience, I'll remind that it's an opt-in feature
>

I don't understand - what is an opt-in feature?


>
>> If this is correct (it's not unreasonable, but should be documented), 
>> then there should also be a simple way to force a kernel entry. But 
>> how to do this using liburing? IIUC if I the following apply:
>>
>>
>>   1. I have no pending sqes
>>
>>   2. There are pending completions
>>
>>   3. There is a completed event for which a completion has not been 
>> appended to the completion queue ring
>>
>>
>> Then io_uring_wait_cqe() will elide io_uring_enter() and the 
>> completed-but-not-reported event will be delayed.
>
> One way is to process all CQEs and then it'll try to enter the
> kernel and do the job.
>
> Another way is to also set IORING_SETUP_TASKRUN_FLAG, then when
> there is work that requires to enter the kernel io_uring will
> set IORING_SQ_TASKRUN in sq_flags.
> Actually, I'm not mistaken io_uring has some automagic handling
> of it internally
>
> https://github.com/axboe/liburing/blob/master/src/queue.c#L36
>
>
>