| Message ID | 20220607080619.513187-1-hao.xu@linux.dev (mailing list archive) |
|---|---|
| Headers | show |
| Series | support nonblock submission for splice pipe to pipe | expand |
Hi, On 6/7/22 16:06, Hao Xu wrote: > From: Hao Xu <howeyxu@tencent.com> > > splice from pipe to pipe is a trivial case, and we can support nonblock > try for it easily. splice depends on iowq at all which is slow. Let's ^ should be 'splice in io_uring' > build a fast submission path for it by supporting nonblock. > > Wrote a simple test to test time spent of splicing from pipe to pipe: > Sorry, forgot to attach the test: https://github.com/HowHsu/liburing/commit/3ff901b4fb80caf66a520742c6542e35111493a0 Regards, Hao
On 6/7/22 09:06, Hao Xu wrote: > From: Hao Xu <howeyxu@tencent.com> > > splice from pipe to pipe is a trivial case, and we can support nonblock > try for it easily. splice depends on iowq at all which is slow. Let's > build a fast submission path for it by supporting nonblock. fwiw, https://www.spinics.net/lists/kernel/msg3652757.html > Wrote a simple test to test time spent of splicing from pipe to pipe: > > > Did 50 times test for each, ignore the highest and lowest number, > calculate the average number: > > before patchset: 119.85 usec > with patchset: 29.5 usec > > ---------------- > I'm not sure if we should use a io_uring specific flag rather than > SPLICE_F_NONBLOCK since from mutex_lock_nest to mutex_trylock changes > the behavior under debug environment I guess. Or maybe there is another > better option than mutex_trylock? > > > Hao Xu (5): > io_uring: move sp->len check up for splice and tee > pipe: add trylock helpers for pipe lock > splice: support nonblock for splice from pipe to pipe > io_uring: support nonblock try for splicing from pipe to pipe > io_uring: add file_in in io_splice{} to avoid duplicate calculation > > fs/pipe.c | 29 +++++++++++++++++++++ > fs/splice.c | 21 +++++++++++++--- > include/linux/pipe_fs_i.h | 2 ++ > io_uring/splice.c | 53 +++++++++++++++++++++++++++++---------- > 4 files changed, 89 insertions(+), 16 deletions(-) > > > base-commit: d8271bf021438f468dab3cd84fe5279b5bbcead8
On 6/7/22 17:27, Pavel Begunkov wrote: > On 6/7/22 09:06, Hao Xu wrote: >> From: Hao Xu <howeyxu@tencent.com> >> >> splice from pipe to pipe is a trivial case, and we can support nonblock >> try for it easily. splice depends on iowq at all which is slow. Let's >> build a fast submission path for it by supporting nonblock. > > fwiw, > > https://www.spinics.net/lists/kernel/msg3652757.html > Thanks, Pavel. Seems it has been discussed for a long time but the result remains unclear...For me, I think this patch is necessary for getting a good SPLICE_F_NONBLOCK user experience.
On 6/7/22 10:19 PM, Hao Xu wrote: > On 6/7/22 17:27, Pavel Begunkov wrote: >> On 6/7/22 09:06, Hao Xu wrote: >>> From: Hao Xu <howeyxu@tencent.com> >>> >>> splice from pipe to pipe is a trivial case, and we can support nonblock >>> try for it easily. splice depends on iowq at all which is slow. Let's >>> build a fast submission path for it by supporting nonblock. >> >> fwiw, >> >> https://www.spinics.net/lists/kernel/msg3652757.html >> > > Thanks, Pavel. Seems it has been discussed for a long time but the > result remains unclear...For me, I think this patch is necessary for > getting a good SPLICE_F_NONBLOCK user experience. I'd just take it up again, this is something we do need to get done to avoid io-wq offload. Which is important...
On 6/8/22 05:19, Hao Xu wrote: > On 6/7/22 17:27, Pavel Begunkov wrote: >> On 6/7/22 09:06, Hao Xu wrote: >>> From: Hao Xu <howeyxu@tencent.com> >>> >>> splice from pipe to pipe is a trivial case, and we can support nonblock >>> try for it easily. splice depends on iowq at all which is slow. Let's >>> build a fast submission path for it by supporting nonblock. >> >> fwiw, >> >> https://www.spinics.net/lists/kernel/msg3652757.html >> > > Thanks, Pavel. Seems it has been discussed for a long time but the > result remains unclear...For me, I think this patch is necessary for getting a good SPLICE_F_NONBLOCK user experience. I quite agree here, something like this is much needed. The performance of io_uring pipe I/O is miserably slow
On 6/7/22 16:06, Hao Xu wrote: > From: Hao Xu <howeyxu@tencent.com> > > splice from pipe to pipe is a trivial case, and we can support nonblock > try for it easily. splice depends on iowq at all which is slow. Let's > build a fast submission path for it by supporting nonblock. > > Wrote a simple test to test time spent of splicing from pipe to pipe: > > > Did 50 times test for each, ignore the highest and lowest number, > calculate the average number: > > before patchset: 119.85 usec > with patchset: 29.5 usec > Hi Al, Any comments on this one? Regards, Hao
From: Hao Xu <howeyxu@tencent.com> splice from pipe to pipe is a trivial case, and we can support nonblock try for it easily. splice depends on iowq at all which is slow. Let's build a fast submission path for it by supporting nonblock. Wrote a simple test to test time spent of splicing from pipe to pipe: Did 50 times test for each, ignore the highest and lowest number, calculate the average number: before patchset: 119.85 usec with patchset: 29.5 usec ---------------- I'm not sure if we should use a io_uring specific flag rather than SPLICE_F_NONBLOCK since from mutex_lock_nest to mutex_trylock changes the behavior under debug environment I guess. Or maybe there is another better option than mutex_trylock? Hao Xu (5): io_uring: move sp->len check up for splice and tee pipe: add trylock helpers for pipe lock splice: support nonblock for splice from pipe to pipe io_uring: support nonblock try for splicing from pipe to pipe io_uring: add file_in in io_splice{} to avoid duplicate calculation fs/pipe.c | 29 +++++++++++++++++++++ fs/splice.c | 21 +++++++++++++--- include/linux/pipe_fs_i.h | 2 ++ io_uring/splice.c | 53 +++++++++++++++++++++++++++++---------- 4 files changed, 89 insertions(+), 16 deletions(-) base-commit: d8271bf021438f468dab3cd84fe5279b5bbcead8