From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Wenchao Hao <haowenchao22@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm: only set fault addrsss' access bit in do_anonymous_page
Date: Tue, 10 Feb 2026 10:07:06 +0100 [thread overview]
Message-ID: <5c4d773c-e3e7-4a71-b250-91701cbdd4a2@kernel.org> (raw)
In-Reply-To: <20260210043456.2137482-1-haowenchao22@gmail.com>
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?
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.
--
Cheers,
David
next prev parent reply other threads:[~2026-02-10 9:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-10 4:34 Wenchao Hao
2026-02-10 9:07 ` David Hildenbrand (Arm) [this message]
2026-02-11 0:49 ` Wenchao Hao
2026-02-11 4:18 ` Dev Jain
2026-02-12 1:42 ` Wenchao Hao
2026-02-12 5:04 ` Dev Jain
2026-02-11 9:05 ` David Hildenbrand (Arm)
2026-02-12 1:57 ` Wenchao Hao
2026-02-12 8:54 ` David Hildenbrand (Arm)
2026-02-13 9:02 ` Wenchao Hao
2026-02-13 9:07 ` David Hildenbrand (Arm)
2026-02-13 14:52 ` Wenchao Hao
2026-02-13 15:08 ` David Hildenbrand (Arm)
2026-02-10 11:56 ` Kiryl Shutsemau
2026-02-11 1:00 ` Wenchao Hao
2026-02-11 11:03 ` Kiryl Shutsemau
2026-02-12 2:08 ` Wenchao Hao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c4d773c-e3e7-4a71-b250-91701cbdd4a2@kernel.org \
--to=david@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=haowenchao22@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox