Re: [PATCH 0/1] pipe: only enable the extra wake_up(rd_wait) when epoll is actually used

[Oleg Nesterov]

On 07/29, Pavel Begunkov wrote:
>
> On 7/25/26 16:19, Oleg Nesterov wrote:
> > On 07/24, Oleg Nesterov wrote:
> > >
> > > Jens, could you confirm? If yes, we need to update the comments in pipe.c
> > > (I've attached 1/1 at the end, so that you can see what this patch does)
> > ...
> > > It seems that IORING_OP_POLL_ADD / IORING_POLL_ADD_MULTI is edge-triggered
> > > by default! Like EPOLL_CTL_ADD / EPOLLET.
> >
> > Yes, sashiko is right. With some help from AI I wrote the simple test-case
>
> https://github.com/axboe/liburing/blob/master/man/io_uring_enter.2#L400
>
> Seems like it's even documented, which is a shame because I deem
> IORING_OP_POLL_ADD + IORING_POLL_ADD_MULTI to be a half broken API that
> should be deprecated after investigating lxc problems with it some years
> back. Makes me wonder, likely it wouldn't even break anything if shifts
> from strict edge definition for pipes. It's a stream, and the user doesn't
> generally know the number of bytes sitting there.

Can't comment, as I said I know nothing about io_uring ;)

Can you look at

	[RFC PATCH v2 1/1] pipe: only enable the extra wake_up(rd_wait) for edge-triggered consumers
	https://lore.kernel.org/all/amdPACI3kw8PobPx@xxxxxxxxxx/

?

Not that I think this patch can improve performance, but to me the
"wait->_key & EPOLLET" check documents the purpose of ->poll_usage.

However, from v2 0/1:

	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.

Oleg.