From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F1B782E9730 for ; Tue, 25 Nov 2025 10:24:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764066271; cv=none; b=WmmT7NZtP3HGLLA5TflKNTnf2FCKtHKSC0bArFsDUii8QRy11Ge6DLaaHU/kyw6d81wWPScIe3WjlhpbyZzsA7c5AqGPlZnrYMwNNiC1ZP7FZZVoUqV+RjK6lz0KSvVGnXJZqythVazDuf3uuzArDcUeOg72AtIvsgVPY6mfECU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764066271; c=relaxed/simple; bh=xU4Ntm/M/6qjUA+H/VJSygdegAetlI7Tj8y4SG/smh0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HfcpiCQH8ajh5pZSi7XaC1JQGIVSWgM7s9658tuM6c5vxEiftFJtrOQGu7gf08hAHWcRI8MzFAa4Pomyeilqo+l2SCVkuiU6okuc93Bc9Ejus6xk6gXapXYHBe2bFUkPStGTXET1j5arKpJHWYIP9dL0w65gfnquroK1nJdLq88= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YVDDijXC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YVDDijXC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A0C9C4CEF1; Tue, 25 Nov 2025 10:24:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764066270; bh=xU4Ntm/M/6qjUA+H/VJSygdegAetlI7Tj8y4SG/smh0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=YVDDijXC5cY+GTiSiG64FIcwf9QR+R30X8Lg6uJpnll9rl18cwmHrVhIjbgN0NWJB bX27uKkhdHfKGBa5F6PKIDGWNdFcCT2YuihUvRxBMjbmsXt+DqHeum2ZGtJTc+F2ZM nToLEY8T/9jSc8cfdZOnvfJhxfvJVio/C1ieuL/0S428HHR3qPFISx0DznIlL2haw8 ACZnJPN07qQn59fAs79kPRo6Fr1ZiVmWYyMle/rLA2vR9+3KFxew02ILswLPhwJQ8C bsJmiOHPV5tQLf9PEeZct7lVHUI3FGWyGWs8zfkBVdm3JzrL2k8ECrhtcVBhYk1Dd5 VgtTd6QdHOIeA== Message-ID: Date: Tue, 25 Nov 2025 11:24:24 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm, hugetlb: implement movable_gigantic_pages sysctl To: Gregory Price , linux-mm@kvack.org, akpm@linux-foundation.org Cc: kernel-team@meta.com, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-kernel@vger.kernel.org, Mel Gorman , Alexandru Moise <00moses.alexander00@gmail.com>, David Rientjes References: <20251121192746.256051-1-gourry@gourry.net> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251121192746.256051-1-gourry@gourry.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/21/25 20:27, Gregory Price wrote: > This reintroduces a concept removed by > commit d6cb41cc44c6 ("mm, hugetlb: remove hugepages_treat_as_movable sysctl") > > This sysctl provides some flexibility between multiple 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. > > However, since there are scenarios where gigantic pages are migratable, > we should allow use of these on movable regions. > > Note: Boot-time CMA is not possible for driver-managed hotplug memory, > as CMA requires the memory to be registered as SystemRAM at boot time. > Additionally, 1GB huge pages are not supported by THP. > > Cc: David Hildenbrand > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Alexandru Moise <00moses.alexander00@gmail.com> > Suggested-by: David Rientjes > Signed-off-by: Gregory Price > Link: https://lore.kernel.org/all/20180201193132.Hk7vI_xaU%25akpm@linux-foundation.org/ > --- > Documentation/admin-guide/sysctl/vm.rst | 17 +++++++++++++++++ > include/linux/hugetlb.h | 3 ++- > mm/hugetlb.c | 11 +++++++++++ > 3 files changed, 30 insertions(+), 1 deletion(-) > > --- > v2: changelog updates > > > diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst > index b325bfbc2611..fe3982604b1f 100644 > --- a/Documentation/admin-guide/sysctl/vm.rst > +++ b/Documentation/admin-guide/sysctl/vm.rst > @@ -54,6 +54,7 @@ Currently, these files are in /proc/sys/vm: > - mmap_min_addr > - mmap_rnd_bits > - mmap_rnd_compat_bits > +- movable_gigantic_pages > - nr_hugepages > - nr_hugepages_mempolicy > - nr_overcommit_hugepages > @@ -623,6 +624,22 @@ This value can be changed after boot using the > /proc/sys/vm/mmap_rnd_compat_bits tunable > > > +movable_gigantic_pages > +====================== > + > +This parameter controls whether gigantic pages may be allocated from > +ZONE_MOVABLE. If set to non-zero, gigantic hugepages can be allocated "gigantic pages" or "gigantic hugetlb pages" > +from ZONE_MOVABLE. ZONE_MOVABLE memory may be created via the kernel > +boot parameter `kernelcore` or via memory hotplug as discussed in > +Documentation/admin-guide/mm/memory-hotplug.rst. > + > +Support may depend on specific architecture. > + > +Note that using ZONE_MOVABLE gigantic pages may make features like > +memory hotremove more unreliable, as migrating gigantic pages is more > +difficult due to needing larger amounts of phyiscally contiguous memory. s/phyiscally/physically/ ? Can we also reference this parameter here from Documentation/admin-guide/mm/memory-hotplug.rst? In particular, there we also talk about gigantic pages and the interaction with ZONE_MOVABLE: " - Gigantic pages are unmovable, resulting in user space consuming a lot of unmovable memory. - Huge pages are unmovable when an architectures does not support huge page migration, resulting in a similar issue as with gigantic pages. " And then later, we talk about "Even with ZONE_MOVABLE, there are some corner cases where offlining a memory block might fail:" where this should be spelled out as well. -- Cheers David