Re: [RFC PATCH] mm/rmap: use release ordering for small-folio mapcount removal

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Wed, Nov 04, 2026 at 05:08:10PM +0000, Pedro Falcato wrote:
> On Wed, Nov 04, 2026 at 08:51:20AM -0800, Pranith Kumar wrote:
> > Hi Lorenzo,
> >
> > On Wed, Nov 4, 2026 at 5:55 AM Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> > >
> > > On Wed, Nov 04, 2026 at 02:37:39PM +0100, David Hildenbrand (Arm) wrote:
> > >
> > > I mean 1.54%, theoretically is even less convincing for me :)
> >
> > With reducing the strength of one barrier, I think this is a non-trivial gain.
>
> Counting cycles on an arm64 simulator for a microbenchmark is completely
> unconvincing.

Exactly.

>
> > >
> > > In any case for something touching a sensitive memory barrier operation to have
> > > a stronger argument put forward for release ordering being suitable than simply
> > > stating it's fine in the commit message and updating a comment.
> > >
> >
> > Can you please explain what information is missing? I think the commit

All of it? Your commit message simply asserts that this is true.

> > message has all the details of why release is sufficient instead of
> > full barrier.
>
> rmap is gnarly code and I'm not sure people have an appetite towards weakening
> random atomic ordering semantics for a virtual 1.54% cycles gain in some
> microbenchmark, without actually explaining why it is safe. __folio_remove_rmap()
> has (indirectly) a lot of callers which may subtly expect different semantics.

Exactly. And this patch boldly decides to CHANGE the invariant here without
evidence for a theorised perf gain.

Sorry we don't have time for this. NAK.

--
Cheers, Lorenzo