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

On Fri, Jul 24, 2026 at 04:54:30PM +0200, Oleg Nesterov wrote:
> On 07/24, Mateusz Guzik wrote:
> >
> > On Fri, Jul 24, 2026 at 3:58 PM Oleg Nesterov <[email protected]> wrote:
> > >
> > > This means that io_uring depends on the "nasty semantics" too, io_poll_wake()
> > > path should add the task work which calls io_req_post_cqe() every time the new
> > > data arrives, even if the pipe was not empty.
> > >
> >
> > well io_uring could set the flag as well in that case? it does not
> > inherently mean random select and poll consumers definitely need this.
> 
> How? I don't think io_uring can do this. It doesn't even know if the file
> is pipe or not. Only file_operations->poll() does know...
> 
> __Perhaps__ pipe_poll() could check something like wait->_key & EPOLLET to
> detect both epoll/io_uring... Not sure, probably not, I'll try to check later.

I got the impression that pipe_poll() sees EPOLLET in wait->_key for
io_uring the same as for EPOLLET epoll. Since d59bd748db0a
("io_uring/poll: disable level triggered poll").

io_poll_add_prep(), which is called before teh proper iouring command,
rejects IORING_POLL_ADD_LEVEL, so io_poll_parse_events() always ORs in
EPOLLET for IORING_OP_POLL_ADD.

The internal apoll path sets EPOLLET unconditionally too
(io_arm_apoll()), so every io_uring poll arming carries it.

Maybe this would work on the set side?

        if ((filp->f_mode & FMODE_READ) && wait &&
            (wait->_key & EPOLLET) &&
            unlikely(!READ_ONCE(pipe->poll_usage)))
                WRITE_ONCE(pipe->poll_usage, true);

--breno