From: Mark Papadakis <[email protected]>
To: [email protected]
Subject: io_uring and spurious wake-ups from eventfd
Date: Tue, 7 Jan 2020 17:55:31 +0200 [thread overview]
Message-ID: <[email protected]> (raw)
This is perhaps an odd request, but if it’s trivial to implement support for this described feature, it could help others like it ‘d help me (I ‘ve been experimenting with io_uring for some time now).
Being able to register an eventfd with an io_uring context is very handy, if you e.g have some sort of reactor thread multiplexing I/O using epoll etc, where you want to be notified when there are pending CQEs to drain. The problem, such as it is, is that this can result in un-necessary/spurious wake-ups.
If, for example, you are monitoring some sockets for EPOLLIN, and when poll says you have pending bytes to read from their sockets, and said sockets are non-blocking, and for each some reported event you reserve an SQE for preadv() to read that data and then you io_uring_enter to submit the SQEs, because the data is readily available, as soon as io_uring_enter returns, you will have your completions available - which you can process.
The “problem” is that poll will wake up immediately thereafter in the next reactor loop iteration because eventfd was tripped (which is reasonable but un-necessary).
What if there was a flag for io_uring_setup() so that the eventfd would only be tripped for CQEs that were processed asynchronously, or, if that’s non-trivial, only for CQEs that reference file FDs?
That’d help with that spurious wake-up.
Thank you,
@markpapadakis
next reply other threads:[~2020-01-07 16:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-07 15:55 Mark Papadakis [this message]
2020-01-07 20:26 ` io_uring and spurious wake-ups from eventfd Jens Axboe
2020-01-07 20:34 ` Jens Axboe
2020-01-08 7:36 ` Mark Papadakis
2020-01-08 16:24 ` Jens Axboe
2020-01-08 16:46 ` Mark Papadakis
2020-01-08 16:50 ` Jens Axboe
2020-01-08 17:20 ` Jens Axboe
2020-01-08 18:08 ` Jens Axboe
2020-01-09 6:09 ` Daurnimator
2020-01-09 15:14 ` Jens Axboe
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] \
/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