Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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



  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