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 2C1E217A2E8 for ; Thu, 4 Dec 2025 06:17:13 +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=1764829034; cv=none; b=RDI/i+kDA+wHMcLUN6Rx5ODDyLXmE9JGAZdq6zp21X6yFnM3i7nxrEsZQz8DNg4HoeEcFfpxmAUY60tNjOPXtDnSf7MrwvsVlrA8prSDZuoLJXo0c73XclSZr0V1d5muiku7kCBx5rsBGq27OWcmz6+EQJ6Y8ROjnfSp4Cdz96c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764829034; c=relaxed/simple; bh=Q8MUdHMvEgmjaaGlAO28ILhZXpbj6vh8gSr4j+aWy4I=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tv4Fdo/jWWM2BgcNdqbZ0ahyaim8AnxozRAMAOVt2GPjILoIcKh2PSc0l/F34A4oY+YQF5sfhBTG+Fk/sCzxDDsXsaQmcX08c2kVogjUYG3f15sS4KCmaB10hv0EsQyeOgK7iYs/Qjx3qUmmaS8HhRcn40FLGqopZkBHLyH7Y9Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rRStUzRD; 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="rRStUzRD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBAE8C113D0; Thu, 4 Dec 2025 06:17:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764829033; bh=Q8MUdHMvEgmjaaGlAO28ILhZXpbj6vh8gSr4j+aWy4I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rRStUzRDg7J6StefxqN06Vm3l470tFr4uFpW1lkwsXV2CHlF9G032x1MxsBtD9JlT kQDVwHTeTi1uRkYUBZLXDH2im/vhjY0njrN203gT3IAcTpfmAxGMa72lSZ4+s0jduq ZG6Ukj3IG3DwHWpuBKiePeewSA9ri5xvMStsLZnbEK6IFCYkJ22HgCsrduq/CoKNYN fU0Qrx94BoGuQVSY1SEZ3Gkm0WxfNgt3pl072vbPl2mXFemK895uribiDls4nD1U8N r1uGyYf+nomV0bFuGqyVJUdUSwpZahS6so2CHBXGx6YkplS1GWzKoqtZ9AZ26SsVtM G3gf9HY/zaOrg== Message-ID: <0b007374-1058-487c-8033-4f0d2830dc89@kernel.org> Date: Thu, 4 Dec 2025 07:17: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] Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb" To: Shuah Khan , akpm@linux-foundation.org Cc: maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, masahiroy@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20251204023358.54107-1-skhan@linuxfoundation.org> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251204023358.54107-1-skhan@linuxfoundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 12/4/25 03:33, Shuah Khan wrote: > This reverts commit 39231e8d6ba7f794b566fd91ebd88c0834a23b98. That was supposed to fix powerpc handling though. So I think we have to understand what is happening here. > > Enabling HAVE_GIGANTIC_FOLIOS broke kernel build and git clone on two > systems. git fetch-pack fails when cloning large repos and make hangs > or errors out of Makefile.build with Error: 139. These failures are > random with git clone failing after fetching 1% of the objects, and > make hangs while compiling random files. On which architecture do we see these issues and with which kernel configs? Can you share one? > > The blow is is one of the git clone failures: > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux_6.19 > Cloning into 'linux_6.19'... > remote: Enumerating objects: 11173575, done. > remote: Counting objects: 100% (785/785), done. > remote: Compressing objects: 100% (373/373), done. > remote: Total 11173575 (delta 534), reused 505 (delta 411), pack-reused 11172790 (from 1) > Receiving objects: 100% (11173575/11173575), 3.00 GiB | 7.08 MiB/s, done. > Resolving deltas: 100% (9195212/9195212), done. > fatal: did not receive expected object 0002003e951b5057c16de5a39140abcbf6e44e50 > fatal: fetch-pack: invalid index-pack output If I would have to guess, these symptoms match what we saw between commit adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio") and commit 5bebe8de1926 ("mm/huge_memory: Fix initialization of huge zero folio"). 5bebe8de1926 went into v6.18-rc7. Just to be sure, are you sure we were able to reproduce this issue with a v6.18-rc7 or even v6.18 that contains 5bebe8de1926? Bisecting might give you wrong results, as the problems of adfb6609c680 do not reproduce reliably. The confusing bit is that MAX_FOLIO_ORDER is mostly used for warnings: $ git grep MAX_FOLIO_ORDER include/linux/mm.h:#define MAX_FOLIO_ORDER MAX_PAGE_ORDER include/linux/mm.h:#define MAX_FOLIO_ORDER PFN_SECTION_SHIFT include/linux/mm.h:#define MAX_FOLIO_ORDER get_order(IS_ENABLED(CONFIG_64BIT) ? SZ_16G : SZ_1G) include/linux/mm.h:#define MAX_FOLIO_ORDER PUD_ORDER include/linux/mm.h:#define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER) mm/hugetlb.c: BUILD_BUG_ON_INVALID(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER); mm/hugetlb.c: WARN_ON(order > MAX_FOLIO_ORDER); mm/internal.h: VM_WARN_ON_ONCE(order > MAX_FOLIO_ORDER); mm/memremap.c: if (WARN_ONCE(pgmap->vmemmap_shift > MAX_FOLIO_ORDER, mm/page_alloc.c: if (WARN_ON_ONCE((gfp_mask & __GFP_COMP) && order > MAX_FOLIO_ORDER)) And MAX_FOLIO_NR_PAGES (derived from MAX_FOLIO_ORDER) is only used in a debug helper $ git grep MAX_FOLIO_NR_PAGES include/linux/mm.h:#define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER) mm/util.c: if (ps->idx < MAX_FOLIO_NR_PAGES) { > > Signed-off-by: Shuah Khan > --- > arch/powerpc/Kconfig | 1 - > arch/powerpc/platforms/Kconfig.cputype | 1 + > include/linux/mm.h | 13 +++---------- > mm/Kconfig | 7 ------- > 4 files changed, 4 insertions(+), 18 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 9537a61ebae0..e24f4d88885a 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -137,7 +137,6 @@ 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 4c321a8ea896..7b527d18aa5e 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -423,6 +423,7 @@ 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 7c79b3369b82..d16b33bacc32 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_HAVE_GIGANTIC_FOLIOS) > +#if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) > /* > * We don't expect any folios that exceed buddy sizes (and consequently > * memory sections). > @@ -2087,17 +2087,10 @@ static inline unsigned long folio_nr_pages(const struct folio *folio) > * pages are guaranteed to be contiguous. > */ > #define MAX_FOLIO_ORDER PFN_SECTION_SHIFT > -#elif defined(CONFIG_HUGETLB_PAGE) > -/* > - * There is no real limit on the folio size. We limit them to the maximum we > - * 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. > + * There is no real limit on the folio size. We limit them to the maximum we > + * currently expect (e.g., hugetlb, dax). > */ > #define MAX_FOLIO_ORDER PUD_ORDER > #endif > diff --git a/mm/Kconfig b/mm/Kconfig > index ca3f146bc705..0e26f4fc8717 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -908,13 +908,6 @@ 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 -- Cheers David