On Sun, 5 May 2024 at 13:02, David Laight <David.Laight@xxxxxxxxxx> wrote: > > How much is the extra pair of atomics going to hurt performance? > IIRC a lot of work was done to (try to) make epoll lockless. If this makes people walk away from epoll, that would be absolutely *lovely*. Maybe they'd start using io_uring instead, which has had its problems, but is a lot more capable in the end. Yes, doing things right is likely more expensive than doing things wrong. Bugs are cheap. That doesn't make buggy code better. Epoll really isn't important enough to screw over the VFS subsystem over. I did point out elsewhere how this could be fixed by epoll() removing the ep items at a different point: https://lore.kernel.org/all/CAHk-=wj6XL9MGCd_nUzRj6SaKeN0TsyTTZDFpGdW34R+zMZaSg@xxxxxxxxxxxxxx/ so if somebody actually wants to fix up epoll properly, that would probably be great. In fact, that model would allow epoll() to just keep a proper refcount as an fd is added to the poll events, and would probably fix a lot of nastiness. Right now those ep items stay around for basically random amounts of time. But maybe there are other ways to fix it. I don't think we have an actual eventpoll maintainer any more, but what I'm *not* willing to happen is eventpoll messing up other parts of the kernel. It was always a ugly performance hack, and was only acceptable as such. "ugly hack" is ok. "buggy ugly hack" is not. Linus
