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

[Wenchao Hao <haowenchao22@gmail.com>]

On Wed, Feb 11, 2026 at 5:05 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 2/11/26 01:49, Wenchao Hao wrote:
> > On Tue, Feb 10, 2026 at 5:07 PM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 2/10/26 05:34, 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.
> >>
> >> What is the use case that cares about that?
> >>
> >
> > We have enabled 64KB large folios on Android devices, which may introduce
> > some memory waste. I want to figure out the proportion of memory waste
> > caused by large folios. Reading the "Referenced" field from /proc/pid/smaps
> > is a relatively low-cost method.
>
> Right. And that imprecision is to be expected when you opt-in into
> something that manages memory in other granularity and only has a single
> a/d bit: a large folio.
>
> Sure, individual PTEs *might* have independent a/d bits, but the
> underlying thing (folio) has only a single one. And optimizations that
> build on top (pte coalescing) reuse that principle that having a single
> logical a/d bit is fine.
>
> >
> > Additionally, considering future hot/cold page identification, we aim to
> > detect 64KB large folios where some pages are actually unaccessed and split
> > them into normal pages to avoid memory waste.
> >
> > However, the current large folio implementation sets the access bit for all
> > page table entries (PTEs) of the large folio in the do_anonymous_page
> > function, making it hard to distinguish whether pre-allocated pages were
> > truly accessed.
>
> The deferred shrinker uses a much simpler mechanism: if the page content
> is zero, likely it was over-allocated and never used later.
>
> It's not completely lightweight (scan pages for 0 content), but is
> reliable, independent of the mapping type (PMD, cont-pte, whatever) and
> independent of any access/dirty bits, leaving performance unharmed.
>
> When you say "I want to figure out the proportion of memory waste", are
> we talking about a debug feature?
>

Thanks for your explanation. I now understand the design logic.

What I’m proposing is mainly for debugging. After enabling 64K large folio
on Android, we observed increased application memory footprint, especially
for anonymous pages.

Since Android app memory usage depends on runtime scenarios, we cannot
confirm if the growth is directly caused by large folio. We want to
analyze memory
usage via the `Referenced` field in `/proc/[pid]/smaps`.

However, with the current 64K anonymous large folio mapping implementation,
the `Referenced` field does not reflect actual page access activity correctly.

This is why I’m sending this RFC patch.

> --
> Cheers,
>
> David