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

[Dev Jain]

On 12/02/26 7:12 am, Wenchao Hao wrote:
> On Wed, Feb 11, 2026 at 12:18 PM Dev Jain <dev.jain@xxxxxxx> wrote:
>>
>> On 11/02/26 6:19 am, 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.
>>>
>>> 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.
>>>
>>>> What we have right now is the exact same behavior as if you would get a
>>>> PMD THP that has a single access+dirty bit at fault time.
>>>>
>>>> Also, architectures that support transparent PTE coalescing will not be
>>>> able to coalesce until all PTE bits are equal.
>>>>
>>>> This level of imprecision is to be expected with large folios that only
>>>> have a single access+dirty bit.
>>>>
>>> Thanks a lot for the response.
>>>
>>> I saw this description in the ARM manual, “D8.5.5 Use of the Contiguous bit
>>> with hardware updates to the translation tables”:
>>>
>>>
>>>> If hardware updates a translation table entry, and if the Contiguous bit in
>>>> that entry is 1, then the members in a group of contiguous translation table
>>>> entries can have different AF, AP[2], and S2AP[1] values.
>>> Does this mean that after hardware aggregates multiple PTEs, it can still
>>> independently set the AF and other flag bits corresponding to specific
>>> sub-PTE?
>> Yes. Hardware can update access and dirty bits per-pte. It is the job
>> of software to aggregate them.
>>
>>> If so, can software also set different AF bits for a group of 16 PTEs
>>> without affecting the transparent PTE coalescing function?
>> Yes. See set_ptes -> __contpte_try_fold: look at pte_mkold(pte_mkclean()).
>> We ignore the a/d bits while constructing the next expected pte.
>>
> Thank you for your answer. I think we can now get the following conclusion:
> From a hardware perspective, after the PTE continuous bit is set, the access
> and dirty flags of the PTE do not affect the transparent PTE
> coalescing function.

Keep in mind that this is the case in software - there is also transparent
coalescing done by hardware, and I am not aware of the spec for that.

>
>>> The reason I have this confusion is that there is such a description in
>>> “D8.7.1 The Contiguous bit:”
>>>
>>>> Software is required to ensure that all of the adjacent translation table
>>>> entries for the contiguous region point to a contiguous OA range with
>>>> consistent attributes and permissions.
>>> It does not specify whether attributes and permissions include the AF bit.
>>>
>>>> --
>>>> Cheers,
>>>>
>>>> David