On Wed, Apr 29, 2026 at 09:27:59AM +0200, Nam Cao wrote:
> Christian Brauner <[email protected]> writes:
> > The selftests rely on this behavior that timeout=0 sees events from a
> > concurrently running producer. They would fail at a very higher rate
> > after this change - believe me I had a similar patch that changed
> > something in this area.
>
> Huh, that's interesting. Do you still remember which selftest cases rely
> on this behavior? I would like to study them further.
>
> > I would explore the seqcount that Mateusz suggested tbh.
>
> I will investigate that.
>
In the meantime I grew fond of another approach: have the write side
re-calc the conditon the unlocked side checks for.
While the seqc thing solves the scalabilty problem, it still requires
fences which are not free on arm.
the goal would be to make it so that this:
static inline int ep_events_available(struct eventpoll *ep)
{
return !list_empty_careful(&ep->rdllist) ||
READ_ONCE(ep->ovflist) != EP_UNACTIVE_PTR;
}
can be converted into:
static inline int ep_events_available(struct eventpoll *ep)
{
return ep->has_events;
}
Which in turn means that any codepath which messes with either rdllist
or ovflist will need to recalc before it ends up unlocking.
Strictly speaking more error prone than the seq approach, but should be
faster on weaker-ordered archs thanks to avoided fences.
I'm definitely not going to protest the seqc route.
