Re: [RFC PATCH] mm: only set fault addrsss' access bit in do_anonymous_page

[Wenchao Hao <haowenchao22@gmail.com>]

On Tue, Feb 10, 2026 at 7:56 PM Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> On Tue, Feb 10, 2026 at 12:34:56PM +0800, Wenchao Hao wrote:
> > When do_anonymous_page() creates mappings for huge pages, it currently sets
> > the access bit for all mapped PTEs (Page Table Entries) by default.
> >
> > This causes an issue where the Referenced field in /proc/pid/smaps cannot
> > distinguish whether a page was actually accessed.
> >
> > So here introduces a new interface, set_anon_ptes(), which only sets the
> > access bit for the PTE corresponding to the faulting address. This allows
> > accurate tracking of page access status in /proc/pid/smaps before memory
> > reclaim scan the folios.
> >
> > During memory reclaim: folio_referenced() checks and clears the access bits
> > of PTEs, rmap verifies all PTEs under a folio. If any PTE mapped subpage of
> > folio has access bit set, the folio is retained during reclaim. So only
> > set the access bit for the faulting PTE in do_anonymous_page() is safe, as
> > it does not interfere with reclaim decisions.
>
> We had similar discussion about faultaround and briefly made it produce
> old ptes, but it caused performance regression as old ptes require
> additional pagewalk to set accessed bit on touch. It got reverted,
> but arch can opt-in for setting up old ptes for non-fault address.
>
> See commits:
>
> 5c0a85fad949 ("mm: make faultaround produce old ptes")
> 315d09bf30c2 ("Revert "mm: make faultaround produce old ptes"")
> 46bdb4277f98 ("mm: Allow architectures to request 'old' entries when prefaulting")
>
It does look similar—our modifications both revolve around whether pre-mapped
PTEs should be marked as "new."

Was there any analysis into why your changes led to performance regressions?
This could help guide whether my modifications are meaningful, and perhaps I
could reference your approach to implement similar changes for different
architectures.

> --
>   Kiryl Shutsemau / Kirill A. Shutemov