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

["David Hildenbrand (Arm)" <david@kernel.org>]

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?

-- 
Cheers,

David