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

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

[Pranith Kumar]

Removing a PTE mapping must precede lowering its folio's mapcount.
The COW path relies on this order to keep the old page from being
reused while a stale translation can still access it. The mapcount
update needs release ordering for that edge, rather than the full
ordering of atomic_add_negative().

Use atomic_add_negative_release() for non-large folios removed at PTE
level. Leave large-folio operations fully ordered; their path can
queue a partially mapped folio for deferred splitting. Update the
COW ordering comment to describe the required guarantee.

In an arm64 page map/unmap microbenchmark with 20,480 minor
faults, simulated cycles fell by 1.54%.

Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
---
 mm/memory.c | 4 ++--
 mm/rmap.c   | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index b65b56fe9714..9e23c64bc743 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4158,9 +4158,9 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
 			 * threads.
 			 *
 			 * The critical issue is to order this
-			 * folio_remove_rmap_pte() with the ptp_clear_flush
+			 * folio_remove_rmap_pte() with the ptep_clear_flush
 			 * above. Those stores are ordered by (if nothing else,)
-			 * the barrier present in the atomic_add_negative
+			 * the release ordering of the mapcount decrement
 			 * in folio_remove_rmap_pte();
 			 *
 			 * Then the TLB flush in ptep_clear_flush ensures that
diff --git a/mm/rmap.c b/mm/rmap.c
index 1131b76bbbc2..62e623d7563b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1794,7 +1794,8 @@ static __always_inline void __folio_remove_rmap(struct folio *folio,
 	switch (level) {
 	case PGTABLE_LEVEL_PTE:
 		if (!folio_test_large(folio)) {
-			nr = atomic_add_negative(-1, &folio->_mapcount);
+			/* Publish the PTE removal before lowering mapcount. */
+			nr = atomic_add_negative_release(-1, &folio->_mapcount);
 			break;
 		}
 
-- 
2.47.3

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

[David Hildenbrand (Arm)]

On 11/4/26 02:31, Pranith Kumar wrote:
> Removing a PTE mapping must precede lowering its folio's mapcount.
> The COW path relies on this order to keep the old page from being
> reused while a stale translation can still access it. The mapcount
> update needs release ordering for that edge, rather than the full
> ordering of atomic_add_negative().
> 
> Use atomic_add_negative_release() for non-large folios removed at PTE
> level. Leave large-folio operations fully ordered; their path can
> queue a partially mapped folio for deferred splitting. Update the
> COW ordering comment to describe the required guarantee.
> 
> In an arm64 page map/unmap microbenchmark with 20,480 minor
> faults, simulated cycles fell by 1.54%.

Thanks for the patch.

While I see value, I am not convinced this is the right time for this
micro-optimization while we are busy with other things.

This needs a better evaluation: 1.54% in a micro-benchmark without knowing the
stddev isn't particularly helpful.

-- 
Cheers,

David

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

[Pranith Kumar]

Hi David,

Thank you for looking at the patch.

On Wed, Nov 4, 2026 at 1:16 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
>
>
> > In an arm64 page map/unmap microbenchmark with 20,480 minor
> > faults, simulated cycles fell by 1.54%.
>
> Thanks for the patch.
>
> While I see value, I am not convinced this is the right time for this
> micro-optimization while we are busy with other things.
>
> This needs a better evaluation: 1.54% in a micro-benchmark without knowing the
> stddev isn't particularly helpful.
>

This result is from a deterministic simulation, hence no stddev.

-- 
Pranith

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

[David Hildenbrand (Arm)]

On 11/4/26 10:46, Pranith Kumar wrote:
> Hi David,
> 
> Thank you for looking at the patch.
> 
> On Wed, Nov 4, 2026 at 1:16 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
>>
>>
>>> In an arm64 page map/unmap microbenchmark with 20,480 minor
>>> faults, simulated cycles fell by 1.54%.
>>
>> Thanks for the patch.
>>
>> While I see value, I am not convinced this is the right time for this
>> micro-optimization while we are busy with other things.
>>
>> This needs a better evaluation: 1.54% in a micro-benchmark without knowing the
>> stddev isn't particularly helpful.
>>
> 
> This result is from a deterministic simulation, hence no stddev.

Ah, I'd assume even a deterministic simulator would have some variance due to
preemption, TLB flushes etc.

But the bigger question is: which arm64 variant is simulated? I'd assume it
might vary heavily no?

-- 
Cheers,

David

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

[Lorenzo Stoakes (ARM)]

On Wed, Nov 04, 2026 at 02:37:39PM +0100, David Hildenbrand (Arm) wrote:
> On 11/4/26 10:46, Pranith Kumar wrote:
> > Hi David,
> >
> > Thank you for looking at the patch.
> >
> > On Wed, Nov 4, 2026 at 1:16 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
> >>
> >>
> >>> In an arm64 page map/unmap microbenchmark with 20,480 minor
> >>> faults, simulated cycles fell by 1.54%.
> >>
> >> Thanks for the patch.
> >>
> >> While I see value, I am not convinced this is the right time for this
> >> micro-optimization while we are busy with other things.
> >>
> >> This needs a better evaluation: 1.54% in a micro-benchmark without knowing the
> >> stddev isn't particularly helpful.
> >>
> >
> > This result is from a deterministic simulation, hence no stddev.
>
> Ah, I'd assume even a deterministic simulator would have some variance due to
> preemption, TLB flushes etc.
>
> But the bigger question is: which arm64 variant is simulated? I'd assume it
> might vary heavily no?

I mean 1.54%, theoretically is even less convincing for me :)

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.

--
Cheers, Lorenzo

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

[Pranith Kumar]

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.

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

Thanks,
--
Pranith

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

[Pedro Falcato]

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

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

[Lorenzo Stoakes (ARM)]

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