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
