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

[Pedro Falcato <pfalcato@suse.de>]

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.

> >
> > 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
> 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.

-- 
Pedro