On Wed, 17 Sep 2025 18:05:45 +0200 Mateusz Guzik <[email protected]> wrote:
> On Wed, Sep 17, 2025 at 3:41 PM Nam Cao <[email protected]> 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. Atomic operations are anything but free.... They are likely to be a similar cost to an uncontested spinlock entry. David
