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 <[email protected]>
---
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
