Re: [RFC PATCH] mm: only set fault addrsss' access bit in do_anonymous_page
From: David Hildenbrand (Arm)
Date: Wed Feb 11 2026 - 04:05:15 EST
On 2/11/26 01:49, Wenchao Hao wrote:
On Tue, Feb 10, 2026 at 5:07 PM David Hildenbrand (Arm)
<david@xxxxxxxxxx> 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