Re: [PATCH] mm/memory: avoid unnecessary #PF on mTHP allocation race
From: Wandun
Date: Tue May 12 2026 - 23:10:36 EST
On 5/12/26 18:35, David Hildenbrand (Arm) wrote:
On 5/12/26 11:50, Wandun Chen wrote: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
When an mTHP folio is allocated in do_anonymous_page() and the targetYes. Why is that a problem?
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.