From: Nico Pache <npache@redhat.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
aarcange@redhat.com, akpm@linux-foundation.org,
anshuman.khandual@arm.com, apopple@nvidia.com,
baohua@kernel.org, baolin.wang@linux.alibaba.com,
byungchul@sk.com, catalin.marinas@arm.com, cl@gentwo.org,
corbet@lwn.net, dave.hansen@linux.intel.com, dev.jain@arm.com,
gourry@gourry.net, hannes@cmpxchg.org, hughd@google.com,
jackmanb@google.com, jack@suse.cz, jannh@google.com,
jglisse@google.com, joshua.hahnjy@gmail.com, kas@kernel.org,
lance.yang@linux.dev, Liam.Howlett@oracle.com,
lorenzo.stoakes@oracle.com, mathieu.desnoyers@efficios.com,
matthew.brost@intel.com, mhiramat@kernel.org, mhocko@suse.com,
peterx@redhat.com, pfalcato@suse.de, rakie.kim@sk.com,
raquini@redhat.com, rdunlap@infradead.org,
richard.weiyang@gmail.com, rientjes@google.com,
rostedt@goodmis.org, rppt@kernel.org, ryan.roberts@arm.com,
shivankg@amd.com, sunnanyong@huawei.com, surenb@google.com,
thomas.hellstrom@linux.intel.com, tiwai@suse.de,
usamaarif642@gmail.com, vbabka@suse.cz, vishal.moola@gmail.com,
wangkefeng.wang@huawei.com, will@kernel.org,
willy@infradead.org, yang@os.amperecomputing.com,
ying.huang@linux.alibaba.com, ziy@nvidia.com,
zokeefe@google.com
Subject: Re: [PATCH mm-unstable v1 3/5] mm/khugepaged: define COLLAPSE_MAX_PTES_LIMIT as HPAGE_PMD_NR - 1
Date: Tue, 24 Feb 2026 17:35:30 -0700 [thread overview]
Message-ID: <CAA1CXcApttZPka9EDdo1fV_ZtktRcXKivQYmLQ=xiwrYFfL4-w@mail.gmail.com> (raw)
In-Reply-To: <493d7898-c959-42ee-ad09-35ffc631ec21@kernel.org>
On Thu, Feb 12, 2026 at 12:51 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 2/12/26 03:18, Nico Pache wrote:
> > The value (HPAGE_PMD_NR - 1) is used often in the khugepaged code to
> > signify the limit of the max_ptes_* values. Add a define for this to
> > increase code readability and reuse.
> >
> > Signed-off-by: Nico Pache <npache@redhat.com>
> > ---
> > mm/khugepaged.c | 15 ++++++++-------
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index c362b3b2e08a..3dcce6018f20 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -85,6 +85,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
> > *
> > * Note that these are only respected if collapse was initiated by khugepaged.
> > */
> > +#define COLLAPSE_MAX_PTES_LIMIT (HPAGE_PMD_NR - 1)
> > unsigned int khugepaged_max_ptes_none __read_mostly;
> > static unsigned int khugepaged_max_ptes_swap __read_mostly;
> > static unsigned int khugepaged_max_ptes_shared __read_mostly;
> > @@ -252,7 +253,7 @@ static ssize_t max_ptes_none_store(struct kobject *kobj,
> > unsigned long max_ptes_none;
> >
> > err = kstrtoul(buf, 10, &max_ptes_none);
> > - if (err || max_ptes_none > HPAGE_PMD_NR - 1)
> > + if (err || max_ptes_none > COLLAPSE_MAX_PTES_LIMIT)
> > return -EINVAL;
> >
> > khugepaged_max_ptes_none = max_ptes_none;
> > @@ -277,7 +278,7 @@ static ssize_t max_ptes_swap_store(struct kobject *kobj,
> > unsigned long max_ptes_swap;
> >
> > err = kstrtoul(buf, 10, &max_ptes_swap);
> > - if (err || max_ptes_swap > HPAGE_PMD_NR - 1)
> > + if (err || max_ptes_swap > COLLAPSE_MAX_PTES_LIMIT)
> > return -EINVAL;
> >
> > khugepaged_max_ptes_swap = max_ptes_swap;
> > @@ -303,7 +304,7 @@ static ssize_t max_ptes_shared_store(struct kobject *kobj,
> > unsigned long max_ptes_shared;
> >
> > err = kstrtoul(buf, 10, &max_ptes_shared);
> > - if (err || max_ptes_shared > HPAGE_PMD_NR - 1)
> > + if (err || max_ptes_shared > COLLAPSE_MAX_PTES_LIMIT)
> > return -EINVAL;
> >
> > khugepaged_max_ptes_shared = max_ptes_shared;
> > @@ -384,7 +385,7 @@ int __init khugepaged_init(void)
> > return -ENOMEM;
> >
> > khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
> > - khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
> > + khugepaged_max_ptes_none = COLLAPSE_MAX_PTES_LIMIT;
> > khugepaged_max_ptes_swap = HPAGE_PMD_NR / 8;
> > khugepaged_max_ptes_shared = HPAGE_PMD_NR / 2;
>
>
> Changing these is ok. I don't like the name either.
Yeah I prefer COLLAPSE_MAX_PTES as others suggested, its shorter and
more general.
>
> It should be clear that they all belong to the "khugepaged_max_ptes" *
> values. (see below)
>
> >
> > @@ -1869,7 +1870,7 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
> > bool is_shmem = shmem_file(file);
> >
> > VM_BUG_ON(!IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && !is_shmem);
> > - VM_BUG_ON(start & (HPAGE_PMD_NR - 1));
> > + VM_BUG_ON(start & (COLLAPSE_MAX_PTES_LIMIT));
> >
> > result = alloc_charge_folio(&new_folio, mm, cc);
> > if (result != SCAN_SUCCEED)
> > @@ -2209,7 +2210,7 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
> > * unwritten page.
> > */
> > folio_mark_uptodate(new_folio);
> > - folio_ref_add(new_folio, HPAGE_PMD_NR - 1);
> > + folio_ref_add(new_folio, COLLAPSE_MAX_PTES_LIMIT);
> >
> > if (is_shmem)
> > folio_mark_dirty(new_folio);
> > @@ -2303,7 +2304,7 @@ static enum scan_result hpage_collapse_scan_file(struct mm_struct *mm, unsigned
> > memset(cc->node_load, 0, sizeof(cc->node_load));
> > nodes_clear(cc->alloc_nmask);
> > rcu_read_lock();
> > - xas_for_each(&xas, folio, start + HPAGE_PMD_NR - 1) {
> > + xas_for_each(&xas, folio, start + COLLAPSE_MAX_PTES_LIMIT) {
> > if (xas_retry(&xas, folio))
> > continue;
> >
>
> Changing these is not. They are semantically something different.
With the new name these are ok right? given we dropped the LIMIT
aspect. The only thing that comes to mind is that COLLAPSE_MAX_PTES
would seemingly refer to 512 not 511, but I'm ok with that if no one
objects.
-- Nico
>
> E.g., folio_ref_add() adds "HPAGE_PMD_NR - 1" because we already
> obtained a reference, and we need one per page -- HPAGE_PMD_NR.
>
> So it's something different than when messing with the magical
> khugepaged_max_ptes_none values.
>
> --
> Cheers,
>
> David
>
next prev parent reply other threads:[~2026-02-25 0:36 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 2:18 [PATCH mm-unstable v1 0/5] mm: khugepaged cleanups and mTHP prerequisites Nico Pache
2026-02-12 2:18 ` [PATCH mm-unstable v1 1/5] mm: consolidate anonymous folio PTE mapping into helpers Nico Pache
2026-02-12 14:38 ` Pedro Falcato
2026-02-12 15:55 ` Joshua Hahn
2026-02-12 19:33 ` Nico Pache
2026-02-12 16:09 ` Zi Yan
2026-02-12 19:45 ` Nico Pache
2026-02-12 20:06 ` Zi Yan
2026-02-12 20:13 ` David Hildenbrand (Arm)
2026-02-12 2:18 ` [PATCH mm-unstable v1 2/5] mm: introduce is_pmd_order helper Nico Pache
2026-02-12 14:40 ` Pedro Falcato
2026-02-12 16:11 ` Zi Yan
2026-02-12 19:45 ` David Hildenbrand (Arm)
2026-02-13 3:51 ` Barry Song
2026-02-14 7:24 ` Lance Yang
2026-02-20 10:38 ` Dev Jain
2026-02-20 10:42 ` David Hildenbrand (Arm)
2026-02-24 2:38 ` Wei Yang
2026-02-12 2:18 ` [PATCH mm-unstable v1 3/5] mm/khugepaged: define COLLAPSE_MAX_PTES_LIMIT as HPAGE_PMD_NR - 1 Nico Pache
2026-02-12 6:56 ` Vernon Yang
2026-02-12 14:45 ` Pedro Falcato
2026-02-12 16:21 ` Zi Yan
2026-02-12 19:51 ` David Hildenbrand (Arm)
2026-02-25 0:35 ` Nico Pache [this message]
2026-02-12 2:23 ` [PATCH mm-unstable v1 4/5] mm/khugepaged: rename hpage_collapse_* to collapse_* Nico Pache
2026-02-12 2:23 ` [PATCH mm-unstable v1 5/5] mm/khugepaged: unify khugepaged and madv_collapse with collapse_single_pmd() Nico Pache
2026-02-12 19:52 ` [PATCH mm-unstable v1 4/5] mm/khugepaged: rename hpage_collapse_* to collapse_* David Hildenbrand (Arm)
2026-02-12 2:25 ` [PATCH mm-unstable v1 5/5] mm/khugepaged: unify khugepaged and madv_collapse with collapse_single_pmd() Nico Pache
2026-02-12 15:33 ` Pedro Falcato
2026-02-12 17:34 ` Zi Yan
2026-02-12 20:03 ` David Hildenbrand (Arm)
2026-02-12 20:26 ` Nico Pache
2026-02-14 8:24 ` Lance Yang
2026-02-23 14:24 ` David Hildenbrand (Arm)
2026-02-23 14:41 ` David Hildenbrand (Arm)
2026-02-24 21:14 ` Nico Pache
2026-02-12 2:26 ` [PATCH mm-unstable v1 0/5] mm: khugepaged cleanups and mTHP prerequisites Nico Pache
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='CAA1CXcApttZPka9EDdo1fV_ZtktRcXKivQYmLQ=xiwrYFfL4-w@mail.gmail.com' \
--to=npache@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=byungchul@sk.com \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=jackmanb@google.com \
--cc=jannh@google.com \
--cc=jglisse@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=matthew.brost@intel.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=rakie.kim@sk.com \
--cc=raquini@redhat.com \
--cc=rdunlap@infradead.org \
--cc=richard.weiyang@gmail.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shivankg@amd.com \
--cc=sunnanyong@huawei.com \
--cc=surenb@google.com \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tiwai@suse.de \
--cc=usamaarif642@gmail.com \
--cc=vbabka@suse.cz \
--cc=vishal.moola@gmail.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yang@os.amperecomputing.com \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
--cc=zokeefe@google.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