Re: [RFC PATCH v2 1/1] pipe: only enable the extra wake_up(rd_wait) for edge-triggered consumers
Pavel Begunkov <[email protected]> Wed, 29 Jul 2026 18:07:43 +0100
| Newsgroups | org.kernel.vger.io-uring,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hey Oleg, On 7/29/26 16:47, Oleg Nesterov wrote: > 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" ? Yep > If yes, I'll send this change as "v3 1/2", rediff this patch on top of it, > and make it "v3 2/2". I should've been clearer, no preference whether it's split into 2 patches or not. >> 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? TLDR, io_uring has something to improve internally after this patch lands. > In particular, I don't understand the "IUC poll callback implementations > don't care about EPOLLET, at least before this patch" part. I was saying that from a quick look I don't see any struct file_operations::poll implementation checking EPOLLET. And if so, it makes changing io_uring easier, only need to consider this patch. > Although it seems you agree that this patch should not break (change the > current behaviour of) io_uring, Yes and right now this is my only concern. > Can you ack/nack my understanding? You got it all right -- Pavel Begunkov