Re: [ISSUE] The time cost of IOSQE_IO_LINK

Carter Li 李通洲
2020-02-15T01:26:06Z

There are at least 2 benefits over POLL->READ

1. Reduce a little complexity of user code, and save lots of sqes.
2. Better performance. Users can’t if an operation will block without
issuing an extra O_NONBLOCK syscall, which ends up with always using
POLL->READ link. If it’s handled by kernel, we may only poll when
we know it’s needed.

> 2020年2月15日 上午9:10，Jens Axboe <axboe@kernel.dk> 写道：
>
> On 2/14/20 5:16 PM, Carter Li 李通洲 wrote:
>> Hello Jens,
>>
>>
>>> It's now up to 3.5x the original performance for the single client case.
>>> Here's the updated patch, folded with the original that only went half
>>> the way there.
>>
>>
>> I’m looking forward to it.
>>
>> And question again: since POLL->READ/RECV is much faster then READ/RECV async,
>> could we implement READ/RECV that would block as POLL->READ/RECV? Not only for
>> networking, but also for all pollable fds.
>
> That's exactly the next step. With this, we have a very efficient way of
> doing async IO for anything that can be driven by poll. Then we can do it
> by default, instead of doing an async punt. Much faster and much more
> efficient.
>
> I'll try and work on that next week, I think this could be a real game
> changer.
>
> --
> Jens Axboe