[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGudoHG9hTwSoordwbMDci5CmnCKMhD330Z0BKfNJ+xUHYC9uA@mail.gmail.com>
Date: Sat, 20 Sep 2025 16:45:36 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: David Laight <david.laight.linux@...il.com>
Cc: Nam Cao <namcao@...utronix.de>, Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, Shuah Khan <shuah@...nel.org>,
Davidlohr Bueso <dave@...olabs.net>, Soheil Hassas Yeganeh <soheil@...gle.com>,
Khazhismel Kumykov <khazhy@...gle.com>, Willem de Bruijn <willemb@...gle.com>,
Eric Dumazet <edumazet@...gle.com>, Jens Axboe <axboe@...nel.dk>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH 2/2] eventpoll: Fix epoll_wait() report false negative
On Sat, Sep 20, 2025 at 4:42 PM David Laight
<david.laight.linux@...il.com> wrote:
>
> On Wed, 17 Sep 2025 18:05:45 +0200
> Mateusz Guzik <mjguzik@...il.com> wrote:
> > 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.
>
In this context it was supposed to be s/refcount/seqcount/ and on
amd64 that's loading the same var twice + a branch for the read thing.
Not *free* but not in the same galaxy comped to acquiring a spinlock
(even assuming it is uncontested).
Powered by blists - more mailing lists