From: Gregory Price <gourry@gourry.net>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>
Cc: linux-mm@kvack.org, kernel-team@meta.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
osalvador@suse.de, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, corbet@lwn.net, muchun.song@linux.dev,
Mel Gorman <mgorman@suse.de>,
Alexandru Moise <00moses.alexander00@gmail.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v3] mm, hugetlb: implement movable_gigantic_pages sysctl
Date: Thu, 4 Dec 2025 12:14:53 -0500 [thread overview]
Message-ID: <aTHBjU5-Fio6CrwD@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <305328e0-3011-409c-a040-76fc478d541a@kernel.org>
On Wed, Dec 03, 2025 at 10:26:20AM +0100, David Hildenbrand (Red Hat) wrote:
> On 12/3/25 07:38, Gregory Price wrote:
> > This reintroduces a concept removed by:
> > commit d6cb41cc44c6 ("mm, hugetlb: remove hugepages_treat_as_movable sysctl")
> >
> > This sysctl provides flexibility between ZONE_MOVABLE use cases:
> > 1) onlining memory in ZONE_MOVABLE to maintain hotplug compatibility
> > 2) onlining memory in ZONE_MOVABLE to make hugepage allocate reliable
> >
> > When ZONE_MOVABLE is used to make huge page allocation more reliable,
> > disallowing gigantic pages memory in this region is pointless. If
> > hotplug is not a requirement, we can loosen the restrictions to allow
> > 1GB gigantic pages in ZONE_MOVABLE.
> >
> > Since 1GB can be difficult to migrate / has impacts on compaction /
> > defragmentation, we don't enable this by default. Notably, 1GB pages
> > can only be migrated if another 1GB page is available - so hot-unplug
> > will fail if such a page cannot be found.
>
> In light of the other discussion: will it fail or will it simplt retry
> forever, until there is a free 1g page?
>
It retries until a 1GB page is available.
Example test:
echo 0 > node0/hugepages/..-1GB/nr_hugepages (dram node)
echo 1 > node1/hugepages/..-1GB/nr_hugepages (zone_movable node)
./alloc_huge & (allocate the page)
./node1_offline & (offline > memory*/state)
sleep 5 (give offline time)
echo 1 > node0/hugepages/..-1GB/nr_hugepages (dram node)
This node1_offline generates migration failures until the last step
occurs, at which point migration and node1_offline complete as expected.
The migration failures produce the following:
[ 707.443105] migrating pfn c080000 failed ret:-12
[ 707.453353] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc080000
[ 707.471315] head: order:18 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0
[ 707.488504] anon flags: 0x17ffff0000000848(uptodate|owner_2|head|node=1|zone=3|lastcpupid=0x1ffff)
[ 707.508393] page_type: f4(hugetlb)
[ 707.515940] raw: 17ffff0000000848 ffa000007d873cc0 ffa000007d873cc0 ff1100082366c6e9
[ 707.533126] raw: 0000000000000000 0000000000000010 00000002f4000000 0000000000000000
[ 707.550317] head: 17ffff0000000848 ffa000007d873cc0 ffa000007d873cc0 ff1100082366c6e9
[ 707.567699] head: 0000000000000000 0000000000000010 00000002f4000000 0000000000000000
[ 707.585085] head: 17ffff0000000012 ffd4000302000001 0000000000000000 0000000000000000
[ 707.602469] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000040000
[ 707.619851] page dumped because: migration failure
I can add this to the changelog if you prefer
~Gregory
next prev parent reply other threads:[~2025-12-04 17:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-03 6:38 [PATCH v3] mm, hugetlb: implement movable_gigantic_pages sysctl Gregory Price
2025-12-03 9:26 ` David Hildenbrand (Red Hat)
2025-12-03 9:36 ` Gregory Price
2025-12-04 17:14 ` Gregory Price [this message]
2025-12-04 20:58 ` David Hildenbrand (Red Hat)
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=aTHBjU5-Fio6CrwD@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=00moses.alexander00@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/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.