Re: [PATCH v6 1/5] mm: rmap: support batched checks of the references for large folios

[Lorenzo Stoakes (Oracle)]

On Thu, Mar 26, 2026 at 09:47:51AM +0800, Baolin Wang wrote:
>
>
> On 3/25/26 11:06 PM, Lorenzo Stoakes (Oracle) wrote:
> > On Wed, Mar 25, 2026 at 03:58:36PM +0100, David Hildenbrand (Arm) wrote:
> > > On 3/25/26 15:36, Lorenzo Stoakes (Oracle) wrote:
> > > > On Mon, Mar 16, 2026 at 03:15:18PM +0100, David Hildenbrand (Arm) wrote:
> > > > > On 3/16/26 07:25, Baolin Wang wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Sure. However, after investigating RISC‑V and x86, I found that
> > > > > > ptep_clear_flush_young() does not flush the TLB on these architectures:
> > > > > >
> > > > > > int ptep_clear_flush_young(struct vm_area_struct *vma,
> > > > > >                 unsigned long address, pte_t *ptep)
> > > > > > {
> > > > > >      /*
> > > > > >       * On x86 CPUs, clearing the accessed bit without a TLB flush
> > > > > >       * doesn't cause data corruption. [ It could cause incorrect
> > > > > >       * page aging and the (mistaken) reclaim of hot pages, but the
> > > > > >       * chance of that should be relatively low. ]
> > > > > >       *
> > > > > >       * So as a performance optimization don't flush the TLB when
> > > > > >       * clearing the accessed bit, it will eventually be flushed by
> > > > > >       * a context switch or a VM operation anyway. [ In the rare
> > > > > >       * event of it not getting flushed for a long time the delay
> > > > > >       * shouldn't really matter because there's no real memory
> > > > > >       * pressure for swapout to react to. ]
> > > > > >       */
> > > > > >      return ptep_test_and_clear_young(vma, address, ptep);
> > > > > > }
> > > > >
> > > > > You'd probably want an arch helper then, that tells you whether
> > > > > a flush_tlb_range() after ptep_test_and_clear_young() is required.
> > > > >
> > > > > Or some special flush_tlb_range() helper.
> > > > >
> > > > > I agree that it requires more work.
>
> (Sorry, David. I forgot to reply to your email because I've had a lot to
> sort out recently.)
>
> Rather than adding more arch helpers (we already have plenty for the young
> flag check), I think we should try removing the TLB flush, as I mentioned to
> Barry[1]. MGLRU reclaim already skips the TLB flush, and it seems to work
> fine. What do you think?
>
> Here are our previous attempts to remove the TLB flush:
>
> My patch: https://lkml.org/lkml/2023/10/24/533
> Barry's patch:
> https://lore.kernel.org/lkml/20220617070555.344368-1-21cnbao@xxxxxxxxx/
>
> [1] https://lore.kernel.org/all/6bdc4b03-9631-4717-a3fa-2785a7930aba@xxxxxxxxxxxxxxxxx/
>
> > > > Sorry unclear here - does the series need more work or does a follow up patch
> > > > need more work?
> > >
> > > Follow up!
> >
> > Ok good as in mm-stable now. Sadly means I don't get to review it but there we
> > go.
>
> Actually this patchset has already been merged upstream:)

Err but this revision was sent _during_ the merge window...?

Was sent on 9th Feb on Monday in merge window week 1, with a functional change
listed:

- Skip batched unmapping for uffd case, reported by Dev. Thanks.

And then sent in 2nd batch on 18th Feb (see [0]).

So we were ok with 1 week of 'testing' (does anybody actually test -next during
the merge window? Was it even sent to -next?) for what appears to be a
functional change?

And there was ongoing feedback on this and the v5 series (at [1])?

This doesn't really feel sane?

And now I'm confused as to whether mm-stable patches can collect tags, since
presumably this was in mm-stable at the point this respin was done?

Maybe I'm missing something here but this doesn't feel like a sane process?

Thanks, Lorenzo

[0]:https://lore.kernel.org/all/20260218200016.8906fb904af9439e7b496327@xxxxxxxxxxxxxxxxxxxx/
[1]:https://lore.kernel.org/linux-mm/cover.1766631066.git.baolin.wang@xxxxxxxxxxxxxxxxx/