From: Oscar Salvador <osalvador@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@redhat.com>,
Muchun Song <muchun.song@linux.dev>, Peter Xu <peterx@redhat.com>,
Gavin Guo <gavinguo@igalia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Oscar Salvador <osalvador@suse.de>
Subject: [PATCH v3 0/5] Misc rework on hugetlb faulting path
Date: Fri, 27 Jun 2025 12:28:59 +0200 [thread overview]
Message-ID: <20250627102904.107202-1-osalvador@suse.de> (raw)
v1 -> v2:
- Addressed issue folio_lock when holding spinlock (per David)
- Simplify new_anon_folio (per David)
- Slightly rework patch#2 to make it simpler
v1 -> v2:
- Addressed feedback from David
- Settle ideas wrt. locking in faulting path after
discussion with David
- Add Acks-by
RFC -> v1:
- Stop looking up folio in the pagecache for detecting a COW
on a private mapping.
- Document the locks
This patchset aims to give some love to the hugetlb faulting path, doing so
by removing obsolete comments that are no longer true, sorting out the folio
lock, and changing the mechanism we use to determine whether we are COWing a
private mapping already.
The most important patch of the series is #1, as it fixes a deadlock that
was described in [1], where two processes were holding the same lock
for the folio in the pagecache, and then deadlocked in the mutex.
Looking up and locking the folio in the pagecache was done to check whether
that folio was the same folio we had mapped in our pagetables, meaning that if it
was different we knew that we already mapped that folio privately, so any
further CoW would be made on a private mapping, which lead us to the question:
__Was the reservation for that address consumed?__
That is all we care about, because if it was indeed consumed and we are the
owner and we cannot allocate more folios, we need to unmap the folio from the
processes pagetables and make it exclusive for us.
We figured we do not need to look up the folio at all, and it is just enough to
check whether the folio we have mapped is anonymous, which means we mapped it
privately, so the reservation was indeed consumed.
Patch#2 sorts out folio locking in the faulting path, reducing the scope of it
,only taking it when we are dealing with an anonymous folio and document it.
More details in the patch.
Patch#3-5 are cleanups.
[1] https://lore.kernel.org/lkml/20250513093448.592150-1-gavinguo@igalia.com/
Oscar Salvador (5):
mm,hugetlb: Change mechanism to detect a COW on private mapping
mm,hugetlb: Sort out folio locking in the faulting path
mm,hugetlb: Rename anon_rmap to new_anon_folio and make it boolean
mm,hugetlb: Drop obsolete comment about non-present pte and second
faults
mm,hugetlb: Drop unlikelys from hugetlb_fault
mm/hugetlb.c | 132 ++++++++++++++++++++++-----------------------------
1 file changed, 56 insertions(+), 76 deletions(-)
--
2.50.0
next reply other threads:[~2025-06-27 10:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 10:28 Oscar Salvador [this message]
2025-06-27 10:29 ` [PATCH v3 1/5] mm,hugetlb: Change mechanism to detect a COW on private mapping Oscar Salvador
2025-06-28 9:22 ` Gavin Guo
2025-06-29 6:53 ` Oscar Salvador
2025-06-29 17:49 ` Oscar Salvador
2025-06-29 20:12 ` Oscar Salvador
2025-06-30 13:26 ` Oscar Salvador
2025-06-27 10:29 ` [PATCH v3 2/5] mm,hugetlb: Sort out folio locking in the faulting path Oscar Salvador
2025-06-27 10:29 ` [PATCH v3 3/5] mm,hugetlb: Rename anon_rmap to new_anon_folio and make it boolean Oscar Salvador
2025-06-27 10:29 ` [PATCH v3 4/5] mm,hugetlb: Drop obsolete comment about non-present pte and second faults Oscar Salvador
2025-06-27 10:29 ` [PATCH v3 5/5] mm,hugetlb: Drop unlikelys from hugetlb_fault Oscar Salvador
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=20250627102904.107202-1-osalvador@suse.de \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gavinguo@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=peterx@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).