All of lore.kernel.org
 help / color / mirror / Atom feed
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
>



      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.