From: Jens Axboe <[email protected]>
To: Josef <[email protected]>,
[email protected], Pavel Begunkov <[email protected]>
Cc: [email protected]
Subject: Re: io_uring process termination/killing is not working
Date: Sun, 16 Aug 2020 10:30:08 -0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 8/15/20 8:20 PM, Jens Axboe wrote:
> On 8/15/20 8:14 PM, Josef wrote:
>>>> Hence it'd be helpful if you explain what your expectations are of
>>>> the program, and how that differs from how it behaves
>>
>> yeah that's true, I'm sorry about that.
>>
>>>> Are you sure your code is correct? I haven't looked too closely, but it
>>>> doesn't look very solid. There's no error checking, and you seem to be
>>>> setting up two rings (one overwriting the other). FWIW, I get the same
>>>> behavior on 5.7-stable and the above branch, except that the 5.7 hangs
>>>> on exit due to the other bug you found and that is fixed in the 5.9
>>>> branch.
>>>>
>>>
>>> Took a closer look, and made a few tweaks. Got rid of the extra links
>>> and the nop, and I added a poll+read resubmit when a read completes.
>>> Not sure how your program could work without that, if you expect it
>>> to continue to echo out what is written on the connection? Also killed
>>> that extra ring init.
BTW, something I think you're aware of, but wanted to bring up
explicitly - if IORING_FEAT_FAST_POLL is available in the ring features,
then you generally don't want/need to link potentially blocking requests
on pollable files with a poll in front. io_uring will do this
internally, and save you an sqe and completion event for each of these
types of requests.
Your test case is a perfect example of that, neither the accept nor the
socket read would need a poll linked in front of them, as they are both
pollable file types and will not trigger use of an async thread to wait
for the event. Instead an internal poll is armed which will trigger the
issue of that request, when the socket is ready.
--
Jens Axboe
next prev parent reply other threads:[~2020-08-16 17:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 17:58 io_uring process termination/killing is not working Josef
2020-08-12 18:05 ` Jens Axboe
2020-08-12 18:20 ` Pavel Begunkov
2020-08-12 18:22 ` Pavel Begunkov
2020-08-12 18:28 ` Pavel Begunkov
2020-08-12 23:32 ` Jens Axboe
2020-08-13 16:07 ` Josef
2020-08-13 16:09 ` Jens Axboe
2020-08-15 7:45 ` Pavel Begunkov
2020-08-15 15:12 ` Jens Axboe
2020-08-15 16:48 ` Pavel Begunkov
2020-08-15 21:43 ` Josef
2020-08-15 22:35 ` Jens Axboe
2020-08-15 23:21 ` Josef
2020-08-15 23:31 ` Jens Axboe
2020-08-16 0:36 ` Josef
2020-08-16 0:41 ` Jens Axboe
2020-08-16 1:21 ` Jens Axboe
2020-08-16 3:14 ` Josef
2020-08-16 3:20 ` Jens Axboe
2020-08-16 17:30 ` Jens Axboe [this message]
2020-08-16 21:09 ` Josef
2020-08-16 22:17 ` Jens Axboe
2020-08-17 8:58 ` Josef
2020-08-17 10:08 ` Pavel Begunkov
2020-08-16 13:45 ` Jens Axboe
2020-08-16 14:53 ` Jens Axboe
2020-08-16 15:22 ` Jens Axboe
2020-08-17 10:16 ` 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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox