On Wed, Sep 17, 2025 at 6:05 PM Mateusz Guzik mjguzik@gmail.com wrote:
On Wed, Sep 17, 2025 at 3:41 PM Nam Cao namcao@linutronix.de wrote:
My question is whether the performance of epoll_wait() with zero timeout is really that important that we have to complicate things. If epoll_wait() with zero timeout is called repeatedly in a loop but there is no event, I'm sure there will be measurabled performance drop. But sane user would just use timeout in that case.
epoll's data is protected by a lock. Therefore I think the most straightforward solution is just taking the lock before reading the data.
I have no idea what the original use case is. I see the author of the patch is cc'ed, so hopefully they will answer.
Lockless is hard to get right and may cause hard-to-debug problems. So unless this performance drop somehow bothers someone, I would prefer "keep it simple, stupid".
Well epoll is known to suffer from lock contention, so I would like to think the lockless games were motivated by a real-world need, but I'm not going peruse the history to find out.
I can agree the current state concerning ep_events_available() is avoidably error prone and something(tm) should be done. fwiw the refcount thing is almost free on amd64, I have no idea how this pans out on arm64.
erm, seqcount