From: Gregory Price <gourry@gourry.net>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org, kernel-team@meta.com,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
vbabka@suse.cz, surenb@google.com, mhocko@suse.com,
jackmanb@google.com, ziy@nvidia.com, kas@kernel.org,
dave.hansen@linux.intel.com, rick.p.edgecombe@intel.com,
muchun.song@linux.dev, osalvador@suse.de, david@redhat.com,
x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org,
Wei Yang <richard.weiyang@gmail.com>,
David Rientjes <rientjes@google.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>
Subject: Re: [PATCH v4] page_alloc: allow migration of smaller hugepages during contig_alloc
Date: Wed, 3 Dec 2025 12:53:12 -0500 [thread overview]
Message-ID: <aTB5CJ0oFfPjavGx@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <20251203173209.GA478168@cmpxchg.org>
On Wed, Dec 03, 2025 at 12:32:09PM -0500, Johannes Weiner wrote:
> On Wed, Dec 03, 2025 at 01:30:04AM -0500, Gregory Price wrote:
> > - if (PageHuge(page))
> > - return false;
> > + /*
> > + * Only consider ranges containing hugepages if those pages are
> > + * smaller than the requested contiguous region. e.g.:
> > + * Move 2MB pages to free up a 1GB range.
>
> This one makes sense to me.
>
> > + * Don't move 1GB pages to free up a 2MB range.
>
> This one I might be missing something. We don't use cma for 2M pages,
> so I don't see how we can end up in this path for 2M allocations.
>
I used 2MB as an example, but the other users (listed in the changelog)
would run into these as well. The contiguous order size seemed
different between each of the 4 users (memtrace, tx, kfence, thp debug).
> The reason I'm bringing this up is because this function overall looks
> kind of unnecessary. Page isolation checks all of these conditions
> already, and arbitrates huge pages on hugepage_migration_supported() -
> which seems to be the semantics you also desire here.
>
> Would it make sense to just remove pfn_range_valid_contig()?
This seems like a pretty clear optimization that was added at some point
to prevent incurring the cost of starting to isolate 512MB of pages and
then having to go undo it because it ran into a single huge page.
for_each_zone_zonelist_nodemask(zone, z, zonelist,
gfp_zone(gfp_mask), nodemask) {
spin_lock_irqsave(&zone->lock, flags);
pfn = ALIGN(zone->zone_start_pfn, nr_pages);
while (zone_spans_last_pfn(zone, pfn, nr_pages)) {
if (pfn_range_valid_contig(zone, pfn, nr_pages)) {
spin_unlock_irqrestore(&zone->lock, flags);
ret = __alloc_contig_pages(pfn, nr_pages,
gfp_mask);
spin_lock_irqsave(&zone->lock, flags);
}
pfn += nr_pages;
}
spin_unlock_irqrestore(&zone->lock, flags);
}
and then
__alloc_contig_pages
ret = start_isolate_page_range(start, end, mode);
This is called without pre-checking the range for unmovable pages.
Seems dangerous to remove without significant data.
~Gregory
next prev parent reply other threads:[~2025-12-03 17:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-03 6:30 Gregory Price
2025-12-03 17:32 ` Johannes Weiner
2025-12-03 17:53 ` Gregory Price [this message]
2025-12-03 18:01 ` Frank van der Linden
2025-12-03 19:43 ` David Hildenbrand (Red Hat)
2025-12-03 20:09 ` Gregory Price
2025-12-03 20:14 ` David Hildenbrand (Red Hat)
2025-12-03 21:50 ` Gregory Price
2025-12-18 15:40 ` Gregory Price
2025-12-03 18:19 ` Johannes Weiner
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=aTB5CJ0oFfPjavGx@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=richard.weiyang@gmail.com \
--cc=rick.p.edgecombe@intel.com \
--cc=rientjes@google.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=x86@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