From: Pavel Begunkov <asml.silence@gmail.com>
To: Hao Xu <haoxu@linux.alibaba.com>, Jens Axboe <axboe@kernel.dk>,
io-uring@vger.kernel.org
Subject: Re: [PATCH] io_uring: fix blocking inline submission
Date: Mon, 14 Jun 2021 11:24:50 +0100 [thread overview]
Message-ID: <238f6b1f-5bbd-1870-43e8-7308acda85a8@gmail.com> (raw)
In-Reply-To: <d8033ef5-f22e-10a7-d836-0e66455327cf@linux.alibaba.com>
On 6/9/21 1:42 PM, Hao Xu wrote:
> 在 2021/6/9 下午7:07, Pavel Begunkov 写道:
>> There is a complaint against sys_io_uring_enter() blocking if it submits
>> stdin reads. The problem is in __io_file_supports_async(), which
>> sees that it's a cdev and allows it to be processed inline.
>>
>> Punt char devices using generic rules of io_file_supports_async(),
>> including checking for presence of *_iter() versions of rw callbacks.
>> Apparently, it will affect most of cdevs with some exceptions like
>> null and zero devices.
>>
>> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
>> ---
>>
>> "...For now, just ensure that anything potentially problematic is done
>> inline". I believe this part is outdated, but what use cases we miss?
>> Anything that we care about?
>>
>> IMHO the best option is to do like in this patch and add
>> (read,write)_iter(), to places we care about.
>>
>> /dev/[u]random, consoles, any else?
>>
> This reminds me another thing, once I did nowait read on a brd(block
> ramdisk), I saw a 10%~30% regression after __io_file_supports_async()
> added. brd is bio based device (block layer doesn't support nowait IO
> for this kind of device), so theoretically it makes sense to punt it to
> iowq threads in advance in __io_file_supports_async(), but actually
> what originally happen is: IOCB_NOWAIT is not delivered to block
> layer(REQ_NOWAIT) and then the IO request is executed inline (It seems
IIUC we fixed it was fixed by
f8b78caf21d5bc3fcfc40c18898f9d52ed1451a5 ("block: don't ignore REQ_NOWAIT for direct IO")
> brd device won't block). This finally makes 'check it in advance'
> slower..
Trying to understand what kind of slower it is... It makes an attempt
to execute it inline. Does it return -EAGAIN? Always succeed
submission (e.g. queued for truly async execution ki_complete style)?
>> fs/io_uring.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>> index 42380ed563c4..44d1859f0dfb 100644
>> --- a/fs/io_uring.c
>> +++ b/fs/io_uring.c
>> @@ -2616,7 +2616,7 @@ static bool __io_file_supports_async(struct file *file, int rw)
>> return true;
>> return false;
>> }
>> - if (S_ISCHR(mode) || S_ISSOCK(mode))
>> + if (S_ISSOCK(mode))
>> return true;
>> if (S_ISREG(mode)) {
>> if (IS_ENABLED(CONFIG_BLOCK) &&
>>
>
--
Pavel Begunkov
next prev parent reply other threads:[~2021-06-14 10:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 11:07 [PATCH] io_uring: fix blocking inline submission Pavel Begunkov
2021-06-09 12:42 ` Hao Xu
2021-06-14 10:24 ` Pavel Begunkov [this message]
2021-06-09 15:07 ` Jens Axboe
2021-06-09 15:34 ` Pavel Begunkov
2021-06-09 15:36 ` Jens Axboe
2021-06-09 15:41 ` Pavel Begunkov
2021-06-09 15:43 ` Jens Axboe
2021-06-09 15:47 ` Pavel Begunkov
2021-06-14 9:30 ` Pavel Begunkov
2021-06-09 15:38 ` Pavel Begunkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=238f6b1f-5bbd-1870-43e8-7308acda85a8@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=haoxu@linux.alibaba.com \
--cc=io-uring@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.