From: Wandun <chenwandun1@gmail.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, ljs@kernel.org, liam@infradead.org,
vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com
Subject: Re: [PATCH] mm/memory: avoid unnecessary #PF on mTHP allocation race
Date: Wed, 13 May 2026 11:10:19 +0800 [thread overview]
Message-ID: <85de3792-596b-4efb-b2a9-89556e098f01@gmail.com> (raw)
In-Reply-To: <220524ba-e39a-4d7f-b44f-d4e2e7132397@kernel.org>
On 5/12/26 18:35, David Hildenbrand (Arm) wrote:
> On 5/12/26 11:50, Wandun Chen wrote:
>> When an mTHP folio is allocated in do_anonymous_page() and the target
>> pte range is not fully empty, current code would release the folio
>> and return.
>>
>> This results an illusion that a page fault has already been processed
>> even if the fact is vmf->address itself is still pte_none(). Another
>> page fault will be triggered again.
> Yes. Why is that a problem?
Honestly, the only data I have is the reproducer; I haven't been able to
show a measurable impact on a real workload. The motivation was "we did
the work of allocatingan mTHP folio and then throw it away just to redo
it from #PF, and this #PF can be avoided by adding a small check +
retry". But as you point out, the second fault path can handle this case
properly, the behaviour is already correct.Please drop the patch. I'll
come back with numbers if I run into a workload where this race is
actually hot.Thanks for taking a look. Best regards, Wandun
>
prev parent reply other threads:[~2026-05-13 3:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 9:50 [PATCH] mm/memory: avoid unnecessary #PF on mTHP allocation race Wandun Chen
2026-05-12 10:35 ` David Hildenbrand (Arm)
2026-05-13 3:10 ` Wandun [this message]
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=85de3792-596b-4efb-b2a9-89556e098f01@gmail.com \
--to=chenwandun1@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.