From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pegase2.c-s.fr (pegase2.c-s.fr [93.17.235.10]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 47CFD26E6EB for ; Sat, 15 Nov 2025 09:50:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=93.17.235.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763200237; cv=none; b=apV7wviW2s5Ai2qVKTZxfYumZhvlcz2OthDGJUa4s2bWUMhsIXh2cdktGTTJqV47ee2jdLjLYbKtKo2KwE69h8FsAf7T05PDbVYJZ2hlNmpPZ7wik/Ks58GG+6MIbSgYFAJSD+EMfdeh93OgJdKuPs2TQVC3SB39uWq2GajYstY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763200237; c=relaxed/simple; bh=7yF5qa03Kbu2PI5zEpofQqdHMPSRO07/Fu/h9DCAnWQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KluwTdf+5jByns3rLMCCjzbXlRTZPdg7xr7xbc/io+IQ3itFS3BZxNQkcs5Xt0YqeEEGltpLgSYKx/bfh3jUL/haOVpvNcoLaRkxO1t3OpI/7mh7Xzr+sZMlKUW9Ql02XLPe4Wdutxd8ibnl53zXamKh/4Kz6wudgH8OeXlhRMY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=csgroup.eu; spf=pass smtp.mailfrom=csgroup.eu; arc=none smtp.client-ip=93.17.235.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=csgroup.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=csgroup.eu Received: from localhost (mailhub4.si.c-s.fr [172.26.127.67]) by localhost (Postfix) with ESMTP id 4d7pnJ3RdWz9sSf; Sat, 15 Nov 2025 10:37:08 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from pegase2.c-s.fr ([172.26.127.65]) by localhost (pegase2.c-s.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSndbvcbPBGm; Sat, 15 Nov 2025 10:37:08 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase2.c-s.fr (Postfix) with ESMTP id 4d7pnJ26rnz9sSY; Sat, 15 Nov 2025 10:37:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 2AFF08B770; Sat, 15 Nov 2025 10:37:08 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 8AuJ7JBTv9yp; Sat, 15 Nov 2025 10:37:08 +0100 (CET) Received: from [192.168.235.99] (unknown [192.168.235.99]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 3D45F8B76E; Sat, 15 Nov 2025 10:37:07 +0100 (CET) Message-ID: Date: Sat, 15 Nov 2025 10:37:06 +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: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb To: "David Hildenbrand (Red Hat)" , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linuxppc-dev , Sourabh Jain , Andrew Morton , "Ritesh Harjani (IBM)" , Madhavan Srinivasan , Donet Tom , Michael Ellerman , Nicholas Piggin , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Nathan Chancellor References: <20251114214920.2550676-1-david@kernel.org> From: Christophe Leroy Content-Language: fr-FR In-Reply-To: <20251114214920.2550676-1-david@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 14/11/2025 à 22:49, David Hildenbrand (Red Hat) a écrit : > In the past, CONFIG_ARCH_HAS_GIGANTIC_PAGE indicated that we support > runtime allocation of gigantic hugetlb folios. In the meantime it evolved > into a generic way for the architecture to state that it supports > gigantic hugetlb folios. > > In commit fae7d834c43c ("mm: add __dump_folio()") we started using > CONFIG_ARCH_HAS_GIGANTIC_PAGE to decide MAX_FOLIO_ORDER: whether we could > have folios larger than what the buddy can handle. In the context of > that commit, we started using MAX_FOLIO_ORDER to detect page corruptions > when dumping tail pages of folios. Before that commit, we assumed that > we cannot have folios larger than the highest buddy order, which was > obviously wrong. > > In commit 7b4f21f5e038 ("mm/hugetlb: check for unreasonable folio sizes > when registering hstate"), we used MAX_FOLIO_ORDER to detect > inconsistencies, and in fact, we found some now. > > Powerpc allows for configs that can allocate gigantic folio during boot > (not at runtime), that do not set CONFIG_ARCH_HAS_GIGANTIC_PAGE and can > exceed PUD_ORDER. > > To fix it, let's make powerpc select CONFIG_ARCH_HAS_GIGANTIC_PAGE with > hugetlb on powerpc, and increase the maximum folio size with hugetlb to 16 > GiB on 64bit (possible on arm64 and powerpc) and 1 GiB on 32 bit (powerpc). > Note that on some powerpc configurations, whether we actually have gigantic > pages depends on the setting of CONFIG_ARCH_FORCE_MAX_ORDER, but there is > nothing really problematic about setting it unconditionally: we just try to > keep the value small so we can better detect problems in __dump_folio() > and inconsistencies around the expected largest folio in the system. > > Ideally, we'd have a better way to obtain the maximum hugetlb folio size > and detect ourselves whether we really end up with gigantic folios. Let's > defer bigger changes and fix the warnings first. > > While at it, handle gigantic DAX folios more clearly: DAX can only > end up creating gigantic folios with HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD. > > Add a new Kconfig option HAVE_GIGANTIC_FOLIOS to make both cases > clearer. In particular, worry about ARCH_HAS_GIGANTIC_PAGE only with > HUGETLB_PAGE. > > Note: with enabling CONFIG_ARCH_HAS_GIGANTIC_PAGE on powerpc, we will now > also allow for runtime allocations of folios in some more powerpc configs. > I don't think this is a problem, but if it is we could handle it through > __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED. Reviewed-by: Christophe Leroy Tested on powerpc 8xx with CONFIG_ARCH_FORCE_MAX_ORDER=8 instead of 9. It is now possible to add hugepages with the following command: echo 4 > /sys/kernel/mm/hugepages/hugepages-8192kB/nr_hugepages But only if CONFIG_CMA is set. Tested-by: Christophe Leroy > > While __dump_page()/__dump_folio was also problematic (not handling dumping > of tail pages of such gigantic folios correctly), it doesn't seem > critical enough to mark it as a fix. > > Fixes: 7b4f21f5e038 ("mm/hugetlb: check for unreasonable folio sizes when registering hstate") > Reported-by: Christophe Leroy > Closes: https://lore.kernel.org/r/3e043453-3f27-48ad-b987-cc39f523060a@csgroup.eu/ > Reported-by: Sourabh Jain > Closes: https://lore.kernel.org/r/94377f5c-d4f0-4c0f-b0f6-5bf1cd7305b1@linux.ibm.com/ > Cc: Andrew Morton > Cc: Ritesh Harjani (IBM) > Cc: Madhavan Srinivasan > Cc: Donet Tom > Cc: Michael Ellerman > Cc: Nicholas Piggin > Cc: Christophe Leroy > Cc: Lorenzo Stoakes > Cc: "Liam R. Howlett" > Cc: Vlastimil Babka > Cc: Mike Rapoport > Cc: Suren Baghdasaryan > Cc: Michal Hocko > Cc: Nathan Chancellor > Signed-off-by: David Hildenbrand (Red Hat) > --- > > v1 -> v2: > * Adjust patch description (typo, 16G vs 1G) > * Remove ARCH_HAS_GIGANTIC_PAGE from arch/powerpc/platforms/Kconfig.cputype > * Mention CONFIG_HAVE_GIGANTIC_FOLIOS in comment > * Use 1 GiB on 32bit to avoid unsigned-long capacity issues > > I yet have to boot-test this on 32bit powerpc. Something for Monday. > > --- > arch/powerpc/Kconfig | 1 + > arch/powerpc/platforms/Kconfig.cputype | 1 - > include/linux/mm.h | 13 ++++++++++--- > mm/Kconfig | 7 +++++++ > 4 files changed, 18 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index e24f4d88885ae..9537a61ebae02 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -137,6 +137,7 @@ config PPC > select ARCH_HAS_DMA_OPS if PPC64 > select ARCH_HAS_FORTIFY_SOURCE > select ARCH_HAS_GCOV_PROFILE_ALL > + select ARCH_HAS_GIGANTIC_PAGE if ARCH_SUPPORTS_HUGETLBFS > select ARCH_HAS_KCOV > select ARCH_HAS_KERNEL_FPU_SUPPORT if PPC64 && PPC_FPU > select ARCH_HAS_MEMBARRIER_CALLBACKS > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype > index 7b527d18aa5ee..4c321a8ea8965 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -423,7 +423,6 @@ config PPC_64S_HASH_MMU > config PPC_RADIX_MMU > bool "Radix MMU Support" > depends on PPC_BOOK3S_64 > - select ARCH_HAS_GIGANTIC_PAGE > default y > help > Enable support for the Power ISA 3.0 Radix style MMU. Currently this > diff --git a/include/linux/mm.h b/include/linux/mm.h > index d16b33bacc32b..7c79b3369b82c 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2074,7 +2074,7 @@ static inline unsigned long folio_nr_pages(const struct folio *folio) > return folio_large_nr_pages(folio); > } > > -#if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) > +#if !defined(CONFIG_HAVE_GIGANTIC_FOLIOS) > /* > * We don't expect any folios that exceed buddy sizes (and consequently > * memory sections). > @@ -2087,10 +2087,17 @@ static inline unsigned long folio_nr_pages(const struct folio *folio) > * pages are guaranteed to be contiguous. > */ > #define MAX_FOLIO_ORDER PFN_SECTION_SHIFT > -#else > +#elif defined(CONFIG_HUGETLB_PAGE) > /* > * There is no real limit on the folio size. We limit them to the maximum we > - * currently expect (e.g., hugetlb, dax). > + * currently expect (see CONFIG_HAVE_GIGANTIC_FOLIOS): with hugetlb, we expect > + * no folios larger than 16 GiB on 64bit and 1 GiB on 32bit. > + */ > +#define MAX_FOLIO_ORDER get_order(IS_ENABLED(CONFIG_64BIT) ? SZ_16G : SZ_1G) > +#else > +/* > + * Without hugetlb, gigantic folios that are bigger than a single PUD are > + * currently impossible. > */ > #define MAX_FOLIO_ORDER PUD_ORDER > #endif > diff --git a/mm/Kconfig b/mm/Kconfig > index 0e26f4fc8717b..ca3f146bc7053 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -908,6 +908,13 @@ config PAGE_MAPCOUNT > config PGTABLE_HAS_HUGE_LEAVES > def_bool TRANSPARENT_HUGEPAGE || HUGETLB_PAGE > > +# > +# We can end up creating gigantic folio. > +# > +config HAVE_GIGANTIC_FOLIOS > + def_bool (HUGETLB_PAGE && ARCH_HAS_GIGANTIC_PAGE) || \ > + (ZONE_DEVICE && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD) > + > # TODO: Allow to be enabled without THP > config ARCH_SUPPORTS_HUGE_PFNMAP > def_bool n > > base-commit: 6146a0f1dfae5d37442a9ddcba012add260bceb0