Re: [PATCH v5 2/2] io_uring: avoid unnecessary io_wq_work copy for fast poll feature

[Jens Axboe <axboe@kernel.dk>]

On 6/7/20 2:36 PM, Pavel Begunkov wrote:
> On 07/06/2020 18:02, Jens Axboe wrote:
>> On 6/3/20 7:46 AM, Pavel Begunkov wrote:
>>> On 02/06/2020 04:16, Xiaoguang Wang wrote:
>>>> hi Jens, Pavel,
>>>>
>>>> Will you have a look at this V5 version? Or we hold on this patchset, and
>>>> do the refactoring work related io_wq_work firstly.
>>>
>>> It's entirely up to Jens, but frankly, I think it'll bring more bugs than
>>> merits in the current state of things.
>>
>> Well, I'd really like to reduce the overhead where we can, particularly
>> when the overhead just exists to cater to the slow path.
>>
>> Planning on taking the next week off and not do too much, but I'll see
>> if I can get some testing in with the current patches.
>>
> 
> I just think it should not be done at expense of robustness.

Oh I totally agree, which is why I've been holding back. I'm just
saying that we're currently doing a number of semi expensive operations
for slow path setup up front, which is annoying and would be nice NOT
to do.

> e.g. instead of having tons of if's around ->func, we can get rid of
> it and issue everything with io_wq_submit_work(). And there are plenty
> of pros of doing that:
> - freeing some space in io_kiocb (in req.work in particular)
> - removing much of stuff with nice negative diffstat
> - helping this series
> - even safer than now -- can't be screwed with memcpy(req).

Definitely sounds good.

> Extra switch-lookup in io-wq shouldn't even be noticeable considering
> punting overhead. And even though io-wq loses some flexibility, as for
> me that's fine as long as there is only 1 user.

Don't care too much about the extra lookups, it's a very minor cost
compared to the wins.

> And then we can go and fix every other problem until this patch set
> looks good.

I'll take a look at your patch.


-- 
Jens Axboe