From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "Nico Pache (Red Hat)" <nico.pache@linux.dev>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v4 4/7] mm/khugepaged: fix outdated comments
Date: Mon, 17 Aug 2026 12:37:27 +0100 [thread overview]
Message-ID: <aoLx6f5pa0yxgBl0@lucifer> (raw)
In-Reply-To: <20260811-khugepaged_pte_refactor-v4-4-ddac39d61c4a@linux.dev>
On Tue, Aug 11, 2026 at 06:48:36AM -0600, Nico Pache (Red Hat) wrote:
> Fix comment in collapse_scan_pmd() that still described the old
> folio_mapcount() > folio_ref_count() check and a "512" false-positive
> scenario. The code now uses folio_expected_ref_count() != folio_ref_count()
> which doesn't suffer from the same limitation.
>
> Fix comment in collapse_huge_page() that referenced ptep_clear_flush,
> when the code actually uses pmdp_collapse_flush.
>
> Fix comment in __collapse_huge_page_swapin() that referenced the old
> function name khugepaged_scan_pmd, now collapse_scan_pmd.
>
> Also clean up some simple typos and stale terminology (mmap_sem ->
> mmap_lock, PG_lock -> folio lock, page -> folio, grammar).
>
> We also clarify a comment regarding where the max_ptes_none check is
> deferred to in mthp_collapse() from the original collapse_scan_pmd check.
>
> Update all comments that references a function to include parentheses.
>
> Acked-by: Usama Arif <usama.arif@linux.dev>
> Assisted-by: Cursor(claude-sonnet-4):4.6
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev>
Thanks, some nits below, but this is some good bit rot fixing here :)
So:
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> mm/khugepaged.c | 44 +++++++++++++++++++++-----------------------
> 1 file changed, 21 insertions(+), 23 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index cae510aa2914..90d6e595d282 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -620,7 +620,7 @@ void __khugepaged_exit(struct mm_struct *mm)
> /*
> * This is required to serialize against
> * collapse_test_exit() (which is guaranteed to run
> - * under mmap sem read mode). Stop here (after we return all
> + * under mmap_lock read mode). Stop here (after we return all
Ah yeah I think there are still quite a few mmap sem's around and people often
refer to it as that almost with nostalgia :)
> * pagetables will be destroyed) until khugepaged has finished
> * working on the pagetables under the mmap_lock.
> */
> @@ -788,8 +788,8 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma,
>
> /*
> * We can do it before folio_isolate_lru because the
> - * folio can't be freed from under us. NOTE: PG_lock
> - * is needed to serialize against split_huge_page
> + * folio can't be freed from under us. NOTE: folio lock
> + * is needed to serialize against split_huge_page()
> * when invoked from the VM.
> */
> if (!folio_trylock(folio)) {
> @@ -815,7 +815,7 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma,
> }
>
> /*
> - * Isolate the page to avoid collapsing an hugepage
> + * Isolate the folio to avoid collapsing a hugepage
> * currently in use by the VM.
> */
> if (!folio_isolate_lru(folio)) {
> @@ -927,7 +927,7 @@ static void __collapse_huge_page_copy_failed(pte_t *pte,
> * Re-establish the PMD to point to the original page table
> * entry. Restoring PMD needs to be done prior to releasing
> * pages. Since pages are still isolated and locked here,
> - * acquiring anon_vma_lock_write is unnecessary.
> + * acquiring anon_vma_lock_write() is unnecessary.
> */
> pmd_ptl = pmd_lock(vma->vm_mm, pmd);
> pmd_populate(vma->vm_mm, pmd, pmd_pgtable(orig_pmd));
> @@ -1101,9 +1101,9 @@ static enum scan_result hugepage_vma_revalidate(struct mm_struct *mm, unsigned l
> return SCAN_VMA_CHECK;
> /*
> * Anon VMA expected, the address may be unmapped then
> - * remapped to file after khugepaged reaquired the mmap_lock.
> + * remapped to file after khugepaged reacquired the mmap_lock.
> *
> - * thp_vma_allowable_orders may return true for qualified file
> + * thp_vma_allowable_orders() may return true for qualified file
> * vmas.
> */
> if (expect_anon && (!(*vmap)->anon_vma || !vma_is_anonymous(*vmap)))
> @@ -1159,7 +1159,7 @@ static enum scan_result check_pmd_still_valid(struct mm_struct *mm,
>
> /*
> * Bring missing pages in from swap, to complete THP collapse.
> - * Only done if khugepaged_scan_pmd believes it is worthwhile.
> + * Only done if collapse_scan_pmd() believes it is worthwhile.
> *
> * For mTHP orders the function bails on the first swap entry, because
> * faulting pages back in during collapse could re-populate PTEs that
> @@ -1227,7 +1227,7 @@ static enum scan_result __collapse_huge_page_swapin(struct mm_struct *mm,
> pte = NULL;
>
> /*
> - * do_swap_page returns VM_FAULT_RETRY with released mmap_lock.
> + * do_swap_page() returns VM_FAULT_RETRY with released mmap_lock.
> * Note we treat VM_FAULT_RETRY as VM_FAULT_ERROR here because
> * we do not retry here and swap entry will remain in pagetable
> * resulting in later failure.
> @@ -1291,7 +1291,7 @@ static enum scan_result alloc_charge_folio(struct folio **foliop, struct mm_stru
> }
>
> /*
> - * collapse_huge_page expects the mmap_lock to be unlocked before entering and
> + * collapse_huge_page() expects the mmap_lock to be unlocked before entering and
> * will always return with the lock unlocked, to avoid holding the mmap_lock
> * while allocating a THP, as that could trigger direct reclaim/compaction.
> * Note that the VMA must be rechecked after grabbing the mmap_lock again.
> @@ -1338,7 +1338,7 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
>
> if (unmapped) {
> /*
> - * __collapse_huge_page_swapin will return with mmap_lock
> + * __collapse_huge_page_swapin() will return with mmap_lock
> * released when it fails. So we jump out_nolock directly in
> * that case. Continuing to collapse causes inconsistency.
> */
> @@ -1351,8 +1351,8 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
> mmap_read_unlock(mm);
> /*
> * Prevent all access to pagetables with the exception of
> - * gup_fast later handled by the ptep_clear_flush and the VM
> - * handled by the anon_vma lock + PG_lock.
> + * gup_fast later handled by the pmdp_collapse_flush() and the VM
> + * handled by the anon_vma lock + folio lock.
> *
> * UFFDIO_MOVE is prevented to race as well thanks to the
> * mmap_lock.
> @@ -1409,9 +1409,9 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
> spin_lock(pmd_ptl);
> VM_WARN_ON_ONCE(!pmd_none(*pmd));
> /*
> - * We can only use set_pmd_at when establishing
> + * We can only use set_pmd_at() when establishing
> * hugepmds and never for establishing regular pmds that
> - * points to regular pagetables. Use pmd_populate for that
> + * points to regular pagetables. Use pmd_populate() for that
> */
> pmd_populate(mm, pmd, pmd_pgtable(_pmd));
> spin_unlock(pmd_ptl);
> @@ -1643,7 +1643,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
>
> /*
> * If PMD is the only enabled order, enforce max_ptes_none, otherwise
> - * scan all pages to populate the bitmap for mTHP collapse.
> + * scan all pages to populate the bitmap for mTHP collapse. The bitmap
> + * is then checked again in mthp_collapse() for each attempted order.
> */
> if (enabled_orders != BIT(HPAGE_PMD_ORDER))
> max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT;
> @@ -1764,12 +1765,9 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> /*
> * Check if the page has any GUP (or other external) pins.
> *
> - * Here the check may be racy:
> - * it may see folio_mapcount() > folio_ref_count().
> - * But such case is ephemeral we could always retry collapse
> - * later. However it may report false positive if the page
> - * has excessive GUP pins (i.e. 512). Anyway the same check
> - * will be done again later the risk seems low.
> + * Here the check is racy, but such case is ephemeral and
> + * we could always retry collapse later. Anyway the same
> + * check will be done again later the risk seems low.
NIT: 'but such case is' -> 'such cases are', 'we could always' -> 'we can
always' and 'the risk seems low' -> 'so the risk seems to be low'.
> */
> if (folio_expected_ref_count(folio) != folio_ref_count(folio)) {
> result = SCAN_PAGE_COUNT;
> @@ -1790,7 +1788,7 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> out_unmap:
> pte_unmap_unlock(pte, ptl);
> if (result == SCAN_SUCCEED) {
> - /* collapse_huge_page expects the lock to be dropped before calling */
> + /* collapse_huge_page() expects the lock to be dropped before calling */
> mmap_read_unlock(mm);
> result = mthp_collapse(mm, start_addr, referenced,
> unmapped, cc, enabled_orders);
>
> --
> 2.55.0
>
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-08-17 11:37 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 12:48 [PATCH v4 0/7] mm/khugepaged: several cleanups Nico Pache (Red Hat)
2026-08-11 12:48 ` [PATCH v4 1/7] mm/khugepaged: refactor per-scan state clearing into collapse_control_init_scan() Nico Pache (Red Hat)
2026-08-12 9:23 ` Pedro Falcato
2026-08-13 0:16 ` Nico Pache (Red Hat)
2026-08-17 4:33 ` Lance Yang
2026-08-11 12:48 ` [PATCH v4 2/7] mm/khugepaged: extract reference check into folio_pte_referenced() helper Nico Pache (Red Hat)
2026-08-11 15:47 ` David Hildenbrand (Arm)
2026-08-13 0:19 ` Nico Pache (Red Hat)
2026-08-17 11:31 ` Lorenzo Stoakes (ARM)
2026-08-11 20:45 ` Zi Yan
2026-08-12 9:19 ` Baolin Wang
2026-08-12 9:25 ` Pedro Falcato
2026-08-17 4:35 ` Lance Yang
2026-08-17 11:32 ` Lorenzo Stoakes (ARM)
2026-08-11 12:48 ` [PATCH v4 3/7] mm/khugepaged: introduce a count_collapse_event() helper Nico Pache (Red Hat)
2026-08-11 20:45 ` Zi Yan
2026-08-12 9:36 ` Pedro Falcato
2026-08-17 4:37 ` Lance Yang
2026-08-17 11:34 ` Lorenzo Stoakes (ARM)
2026-08-11 12:48 ` [PATCH v4 4/7] mm/khugepaged: fix outdated comments Nico Pache (Red Hat)
2026-08-11 20:48 ` Zi Yan
2026-08-12 9:38 ` Pedro Falcato
2026-08-17 4:37 ` Lance Yang
2026-08-17 11:37 ` Lorenzo Stoakes (ARM) [this message]
2026-08-11 12:48 ` [PATCH v4 5/7] mm/khugepaged: Refactor the PTE state checks into a helper Nico Pache (Red Hat)
2026-08-12 2:04 ` Zi Yan
2026-08-12 8:40 ` David Hildenbrand (Arm)
2026-08-12 9:51 ` David Hildenbrand (Arm)
2026-08-12 10:06 ` David Hildenbrand (Arm)
2026-08-13 2:14 ` Zi Yan
2026-08-13 7:13 ` David Hildenbrand (Arm)
2026-08-14 13:58 ` Zi Yan
2026-08-12 19:39 ` Andrew Morton
2026-08-12 20:56 ` David Hildenbrand (Arm)
2026-08-13 2:12 ` Nico Pache (Red Hat)
2026-08-13 20:53 ` Andrew Morton
2026-08-12 10:50 ` Pedro Falcato
2026-08-11 12:48 ` [PATCH v4 6/7] mm/khugepaged: unmap pte before releasing vma write lock Nico Pache (Red Hat)
2026-08-11 20:54 ` Zi Yan
2026-08-12 9:21 ` Baolin Wang
2026-08-12 10:51 ` Pedro Falcato
2026-08-17 4:40 ` Lance Yang
2026-08-17 11:38 ` Lorenzo Stoakes (ARM)
2026-08-11 12:48 ` [PATCH v4 7/7] mm: Documentation: clarify where the mTHP stats live Nico Pache (Red Hat)
2026-08-11 20:54 ` Zi Yan
2026-08-12 10:52 ` Pedro Falcato
2026-08-17 4:41 ` Lance Yang
2026-08-17 12:37 ` Lorenzo Stoakes (ARM)
2026-08-11 18:23 ` [PATCH v4 0/7] mm/khugepaged: several cleanups Andrew Morton
2026-08-11 18:55 ` David Hildenbrand (Arm)
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=aoLx6f5pa0yxgBl0@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=nico.pache@linux.dev \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=ziy@nvidia.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