From: "Zi Yan" <ziy@nvidia.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
"Nico Pache (Red Hat)" <nico.pache@linux.dev>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"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 5/7] mm/khugepaged: Refactor the PTE state checks into a helper
Date: Wed, 12 Aug 2026 22:14:46 -0400 [thread overview]
Message-ID: <DKNGC4X9V83D.268DMWU0WIILG@nvidia.com> (raw)
In-Reply-To: <753cb38f-66b4-4bd0-8b53-7480efe30ec3@kernel.org>
On Wed Aug 12, 2026 at 5:51 AM EDT, David Hildenbrand (Arm) wrote:
>> Huh, that looks odd.
>>
>> That should just be a VM_WARN_ON_FOLIO(true, ..) or sth like that.
>>
>> But in collapse_scan_pmd() that warning never existed? So this raises eyebrows.
>>
>> [...]
>>
>> I'll play with it to see if we can do better and will reply here later.
>
>
> Okay, I think below is what we should do.
>
> There is one behavioral change: we now longer trace the last folio, which is the right
> thing to do IMHO.
>
> And I think there is one fix we should pull out and evaluate first: A zeropage with a
> uffd-wp marker is not checked properly, IIUC.
>
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 5a06e3942e889..8a223659fce2d 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -119,6 +119,18 @@ struct collapse_control {
> DECLARE_BITMAP(mthp_present_ptes, MAX_PTRS_PER_PTE);
> };
>
> +struct collapse_anon_pte_check_ctx {
> + struct collapse_control *cc;
> + struct vm_area_struct *vma;
> + unsigned int order;
> + int none_or_zero_ptes;
> + int nonpresent_ptes;
> + int shared_ptes;
> + unsigned int max_ptes_none;
> + int max_ptes_swap;
> + unsigned int max_ptes_shared;
> +};
> +
> /**
> * struct khugepaged_scan - cursor for scanning
> * @mm_head: the head of the mm list to scan
> @@ -696,74 +708,104 @@ static void count_collapse_event(unsigned int order, enum vm_event_item vm_event
> count_mthp_stat(order, mthp_event);
> }
>
> +static enum scan_result collapse_anon_pte_check(pte_t pteval,
> + unsigned long addr, struct collapse_anon_pte_check_ctx *ctx,
> + struct folio **foliop)
> +{
> + *foliop = NULL;
> +
> + /*
> + * Don't collapse if any of the small PTEs are armed with uffd
> + * write protection. Marking the new huge pmd as write protected
> + * could bring userfault messages that fall outside of the
> + * registered range.
> + */
> + if ((pte_present(pteval) && pte_uffd(pteval)) ||
> + (!pte_present(pteval) && pte_swp_uffd_any(pteval)))
> + return SCAN_PTE_UFFD;
> +
> + if (pte_none_or_zero(pteval)) {
> + if (++ctx->none_or_zero_ptes > ctx->max_ptes_none) {
> + count_collapse_event(ctx->order, THP_SCAN_EXCEED_NONE_PTE,
> + MTHP_STAT_COLLAPSE_EXCEED_NONE);
> + return SCAN_EXCEED_NONE_PTE;
> + }
> + return SCAN_SUCCEED;
> + }
> + if (!pte_present(pteval)) {
> + if (ctx->max_ptes_swap < 0)
> + return SCAN_PTE_NON_PRESENT;
> + if (++ctx->nonpresent_ptes > ctx->max_ptes_swap) {
So max_ptes_swap is actually max_ptes_nonpresent. But due to
khugepaged's max_ptes_swap config name, we just keep the variable and
related function names that way?
> + count_collapse_event(ctx->order, THP_SCAN_EXCEED_SWAP_PTE,
> + MTHP_STAT_COLLAPSE_EXCEED_SWAP);
> + return SCAN_EXCEED_SWAP_PTE;
> + }
> + return SCAN_SUCCEED;
> + }
> +
> + *foliop = vm_normal_folio(ctx->vma, addr, pteval);
> + if (unlikely(!*foliop) || unlikely(folio_is_zone_device(*foliop)))
> + return SCAN_PAGE_NULL;
> +
> + /*
> + * If the vma has the VM_DROPPABLE flag, the collapse will
> + * preserve the lazyfree property without needing to skip.
> + */
> + if (ctx->cc->is_khugepaged && !(ctx->vma->vm_flags & VM_DROPPABLE) &&
> + folio_test_lazyfree(*foliop) && !pte_dirty(pteval))
> + return SCAN_PAGE_LAZYFREE;
> +
> + if (!folio_test_anon(*foliop))
> + return SCAN_PAGE_ANON;
> +
> + if (folio_maybe_mapped_shared(*foliop)) {
> + /*
> + * TODO: Support shared pages without leading to further
> + * mTHP collapses. Currently bringing in new pages via
> + * shared may cause a future higher order collapse on a
> + * rescan of the same range.
> + */
> + if (++ctx->shared_ptes > ctx->max_ptes_shared) {
> + count_collapse_event(ctx->order, THP_SCAN_EXCEED_SHARED_PTE,
> + MTHP_STAT_COLLAPSE_EXCEED_SHARED);
> + return SCAN_EXCEED_SHARED_PTE;
> + }
> + }
> +
> + return SCAN_SUCCEED;
> +}
> +
> static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma,
> unsigned long start_addr, pte_t *pte, struct collapse_control *cc,
> unsigned int order, struct list_head *compound_pagelist)
> {
<snip>
> + result = collapse_anon_pte_check(pteval, addr, &ctx, &folio);
> + if (result != SCAN_SUCCEED) {
> + VM_WARN_ON_ONCE(result == SCAN_PAGE_ANON);
> goto out;
> }
> + if (!folio)
> + continue;
SCAN_SUCCEED + folio != NULL means to proceed with the pte, while
SCAN_SUCCEED + folio == NULL means to skip the pte.
collapse_anon_pte_check() probably needs to document this? Yes, it is
straightforward at the call sites, since without a folio the following
code cannot be executed. Or you think that is self-documented.
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-08-13 2:14 UTC|newest]
Thread overview: 36+ 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-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-11 20:45 ` Zi Yan
2026-08-12 9:19 ` Baolin Wang
2026-08-12 9:25 ` Pedro Falcato
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-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-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 [this message]
2026-08-13 7:13 ` David Hildenbrand (Arm)
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-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-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-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=DKNGC4X9V83D.268DMWU0WIILG@nvidia.com \
--to=ziy@nvidia.com \
--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=ljs@kernel.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 \
/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