IO-Uring Archive on
 help / color / Atom feed
From: Mark Papadakis <>
Subject: io_uring and spurious wake-ups from eventfd
Date: Tue, 7 Jan 2020 17:55:31 +0200
Message-ID: <> (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,

             reply index

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 ` 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 publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

IO-Uring Archive on

Archives are clonable:
	git clone --mirror io-uring/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 io-uring io-uring/ \
	public-inbox-index io-uring

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone