From: "Zi Yan" <ziy@nvidia.com>
To: "Joanne Koong" <joannelkoong@gmail.com>,
<akpm@linux-foundation.org>, <david@kernel.org>, <ljs@kernel.org>
Cc: <baohua@kernel.org>, <usama.arif@linux.dev>, <hannes@cmpxchg.org>,
<kas@kernel.org>, <alex@ghiti.fr>,
<baolin.wang@linux.alibaba.com>, <liam@infradead.org>,
<npache@redhat.com>, <ryan.roberts@arm.com>, <dev.jain@arm.com>,
<lance.yang@linux.dev>, <vbabka@kernel.org>, <rppt@kernel.org>,
<surenb@google.com>, <mhocko@suse.com>, <willy@infradead.org>,
<linux-mm@kvack.org>
Subject: Re: [PATCH v4 1/4] mm/huge_memory: scale thp_underused() to the folio size
Date: Mon, 09 Nov 2026 22:54:41 -0500 [thread overview]
Message-ID: <DMR874E7OJFG.160T3TW5FF6PL@nvidia.com> (raw)
In-Reply-To: <20261103212004.1356327-2-joannelkoong@gmail.com>
On Tue Nov 3, 2026 at 4:20 PM EST, Joanne Koong wrote:
> thp_underused() decides whether a large folio on the deferred split list
> is underused and should be split so that its zero-filled subpages can be
> reclaimed.
>
> Today it only ever runs on PMD-sized folios, so it assumes that the
> folio has HPAGE_PMD_NR pages and compares the zero-filled page count
> directly against khugepaged_max_ptes_none. A later patch will queue
> anonymous mTHP folios onto the deferred split list as well, at which
> point that assumption will no longer hold.
>
> Make thp_underused() folio-size-aware, and scale
> khugepaged_max_ptes_none proportionally to the number of pages in the
> folio (eg every folio tolerates the same fraction of zero-filled pages
> the user configured for a PMD-sized folio).
>
> khugepaged deliberately doesn't scale intermediate values when
> collapsing to mTHP orders (to avoid the memory footprint creeping up
> through repeated collapses), but if/when collapse later gains support
> for intermediate values, a folio that khugepaged collapses won't then be
> split right back by the shrinker (and vice versa) since both collapse
> and split would use the same threshold for a given folio size.
>
> There is no functional change for PMD-sized folios, as for those,
> nr_pages is HPAGE_PMD_NR.
>
> Suggested-by: Usama Arif <usama.arif@linux.dev>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> ---
> mm/huge_memory.c | 20 ++++++++++++++------
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 14599d0fff01..3720c12bdb0d 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -4625,25 +4625,33 @@ static unsigned long deferred_split_count(struct shrinker *shrink,
>
> static bool thp_underused(struct folio *folio)
> {
> - int num_zero_pages = 0, num_filled_pages = 0;
> - int i;
> + const unsigned long nr_pages = folio_nr_pages(folio);
> + unsigned long num_zero_pages = 0, num_filled_pages = 0;
> + unsigned long max_ptes_none = khugepaged_max_ptes_none;
> + unsigned long i;
>
> - if (khugepaged_max_ptes_none == HPAGE_PMD_NR - 1)
> + if (max_ptes_none == HPAGE_PMD_NR - 1)
> return false;
>
> if (folio_contain_hwpoisoned_page(folio))
> return false;
>
> - for (i = 0; i < folio_nr_pages(folio); i++) {
> + /*
> + * khugepaged_max_ptes_none is a number of pages out of HPAGE_PMD_NR.
> + * Scale it to this folio's size.
It is better to document max_ptes_none is different from what khugepaged does,
especially khugepaged_max_ptes_none is mentioned above.
> + */
> + max_ptes_none = max_ptes_none * nr_pages / HPAGE_PMD_NR;
> +
> + for (i = 0; i < nr_pages; i++) {
> if (pages_identical(folio_page(folio, i), ZERO_PAGE(0))) {
> - if (++num_zero_pages > khugepaged_max_ptes_none)
> + if (++num_zero_pages > max_ptes_none)
> return true;
> } else {
> /*
> * Another path for early exit once the number
> * of non-zero filled pages exceeds threshold.
> */
> - if (++num_filled_pages >= HPAGE_PMD_NR - khugepaged_max_ptes_none)
> + if (++num_filled_pages >= nr_pages - max_ptes_none)
> return false;
> }
> }
Otherwise, LGTM.
Acked-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-11-10 3:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 21:20 [PATCH v4 0/4] mm: split underused anonymous mTHP folios Joanne Koong
2026-11-03 21:20 ` [PATCH v4 1/4] mm/huge_memory: scale thp_underused() to the folio size Joanne Koong
2026-11-05 12:20 ` Kiryl Shutsemau
2026-11-10 3:54 ` Zi Yan [this message]
2026-11-12 23:50 ` Joanne Koong
2026-11-10 8:00 ` Baolin Wang
2026-11-03 21:20 ` [PATCH v4 2/4] mm/huge_memory: don't queue folios when underused splitting is inactive Joanne Koong
2026-11-03 22:15 ` Usama Arif
2026-11-05 12:23 ` Kiryl Shutsemau
2026-11-10 8:13 ` Baolin Wang
2026-11-03 21:20 ` [PATCH v4 3/4] mm/huge_memory: add a per-order counter for underused splits Joanne Koong
2026-11-03 22:20 ` Usama Arif
2026-11-05 12:26 ` Kiryl Shutsemau
2026-11-06 0:06 ` Joanne Koong
2026-11-10 8:10 ` Baolin Wang
2026-11-03 21:20 ` [PATCH v4 4/4] mm: add anonymous mTHP folios to the deferred split list Joanne Koong
2026-11-03 22:20 ` Barry Song
2026-11-04 21:21 ` sashiko-bot
2026-11-04 23:50 ` Joanne Koong
2026-11-05 12:37 ` Kiryl Shutsemau
2026-11-06 0:05 ` Joanne Koong
2026-11-09 22:29 ` Joanne Koong
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=DMR874E7OJFG.160T3TW5FF6PL@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=joannelkoong@gmail.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.