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

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

On Mon, Mar 16, 2026 at 03:15:18PM +0100, David Hildenbrand (Arm) wrote:
> On 3/16/26 07:25, Baolin Wang wrote:
> >
> >
> > On 3/10/26 4:17 PM, David Hildenbrand (Arm) wrote:
> >> On 3/10/26 02:37, Baolin Wang wrote:
> >>>
> >>>
> >>>
> >>> I understand your point. I’m concerned that I can’t test this patch on
> >>> every architecture to validate the benefits. Anyway, let me try this on
> >>> my X86 machine first.
> >>
> >> In any case, please make that a follow-up patch :)
> >
> > 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 unclear here - does the series need more work or does a follow up patch
need more work?

As this is in mm-stable afaict.

Thanks, Lorenzo

>
> --
> Cheers,
>
> David