From: Oleg Nesterov <oleg@redhat.com>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: Breno Leitao <leitao@debian.org>,
Christian Brauner <brauner@kernel.org>,
Mateusz Guzik <mjguzik@gmail.com>, Jens Axboe <axboe@kernel.dk>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Alexey Gladkov <legion@kernel.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
io-uring@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/1] pipe: only enable the extra wake_up(rd_wait) for edge-triggered consumers
Date: Wed, 29 Jul 2026 17:47:05 +0200 [thread overview]
Message-ID: <amogeROg0Hthp7HD@redhat.com> (raw)
In-Reply-To: <1bd5710b-29c8-4a8c-8f26-72d9e71c2321@gmail.com>
Pavel, thanks for taking the look!
But let me ask a couple of questions to ensure I really understand you.
On 07/29, Pavel Begunkov wrote:
>
> On 7/27/26 13:28, Oleg Nesterov wrote:
> > pipe_poll() unconditionally sets poll_usage on the first call, forcing
> > anon_pipe_write() to wake up readers on every write even if the pipe was
> > not empty. But this is only needed for edge-triggered consumers: epoll
> > with EPOLLET and io_uring without (unsupported) IORING_POLL_ADD_LEVEL.
> > poll() and select() users pay for it for no reason.
>
> Sounds good, especially with prep patches you mentioned.
By prep patches you mean the
With or without this patch we need to update the comments to document
that io_uring depends on ->pipe_usage too. And probably rename it to
(say) ->et_poll.
note in "v2 0/1" ?
If yes, I'll send this change as "v3 1/2", rediff this patch on top of it,
and make it "v3 2/2".
> The only note your problems are caused by IORING_OP_POLL_ADD, which
> is not that important comparing to other polled io_uring requests,
> and they also set EPOLLET while should be fine with level. Not
> asking to change anything, io_uring should just stop setting EPOLLET
> for them. And IIUC poll callback implementations don't care about
> EPOLLET, at least before this patch.
Sorry, I am a bit confused, could you add more details?
In particular, I don't understand the "IUC poll callback implementations
don't care about EPOLLET, at least before this patch" part.
Although it seems you agree that this patch should not break (change the
current behaviour of) io_uring, and right now this is my only concern.
Can you ack/nack my understanding?
Thanks!
Oleg.
next prev parent reply other threads:[~2026-07-29 15:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 12:23 [RFC PATCH v 0/1] pipe: only enable the extra wake_up(rd_wait) for edge-triggered consumers Oleg Nesterov
2026-07-27 12:24 ` [RFC PATCH v2 " Oleg Nesterov
2026-07-27 12:28 ` Oleg Nesterov
2026-07-28 7:41 ` Christian Brauner
2026-07-27 12:28 ` [RFC PATCH v2 1/1] " Oleg Nesterov
2026-07-29 14:58 ` Pavel Begunkov
2026-07-29 15:47 ` Oleg Nesterov [this message]
2026-07-29 17:07 ` 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=amogeROg0Hthp7HD@redhat.com \
--to=oleg@redhat.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=legion@kernel.org \
--cc=leitao@debian.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).