From nobody Fri Dec 19 19:33:22 2025 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 548612F12CC for ; Thu, 4 Dec 2025 02:34:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764815645; cv=none; b=ZBY9XRxlTUtJI8NcFUzRL7enC0Awfn8MNDykoMQqOZlVkWw/dK1YVCLe3d4N18S/7bPcHNq1K99nmGBbl2SuhpxSevAOQLQrnWmq9oJ0vz1DrTRYAGTUEhYY8lq9/z5lthk6DfqZYN4Z1skNpa1nYWckzVneKTW1JIWG9Hybnv8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764815645; c=relaxed/simple; bh=5UxdLh9WxAmJlJyTy62QHvsW5LYugb3ZcfzQCInS5EM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=H/X7rES/AYRX2WfR5wTtCwxrtUPZAhG4pJmVUz6Q/1l48j/sqNaRkwRuEwcySYOL3kx+4vImlPfRkMLgIXl+kr9A/pkwrHQWHl6vI0Yi6WstR7qIwot1+gRAIBmlfLL2igROxF0HuGSEnt6quEhUj7T5ZHqKci+g3YbEUIF/2IE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxfoundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=gBJIi1v+; arc=none smtp.client-ip=209.85.210.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="gBJIi1v+" Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-7c6ce4f65f7so417053a34.0 for ; Wed, 03 Dec 2025 18:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; t=1764815641; x=1765420441; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=8cBwp0aWYwyhGai8JhHTyTaXAP5UhX6tjhsjDn6rkoQ=; b=gBJIi1v+e74AYa8kckgmfHUZgI1NRmilB63vWlmjpAE7c8PKRN5YqMyZ72hS8XEJGK MbC+AdxywlPalUqD1tBvX0/6P9ah7h3Ac/nYrODyPedRlaef2tpdOMPAIlZ4OG0CsCd6 xV4QsBuvff0g2cz2ya41uGpT8JSacXsW+xuNc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764815641; x=1765420441; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8cBwp0aWYwyhGai8JhHTyTaXAP5UhX6tjhsjDn6rkoQ=; b=ikVN79Zh7wHZYP0J4NUwXfzCGkwd32shLxCdKmy3evnn810Pfn5UYsLqXhd0+wyKop XlzvxgxpMgPjP1GCOzIqRhjdDR+E2NhK8EF2QwUpMIhtW3NapZJCerGny5R8glMlbpC3 Ain3qUqvo5haJMRUwO3vOJEYChcojZ8dwHbjhok4epPFT7dfE78ROzNg5Zj4t73IsQc1 cTcdhatBfPvEwmMzjCy/+jwy/sIjdSXbVzswCVXLClciOEAqDaHTZBRc0yl1k5i8gGRs Fq9XnvwkTn98SsRXP84/mIJBxU5xPG95NfUJLvXi/pEzuDyEGKJ83PEAcgNtD6j/NnGm Gbnw== X-Forwarded-Encrypted: i=1; AJvYcCUEpzbZN7xDk44V8xQtnaqS9CPyyqjSNTNaGzSD7+/u0bpJz1aKqyC8o77ttuC96vSg5UcAaWpIw1gQEuU=@vger.kernel.org X-Gm-Message-State: AOJu0YzaqL2U0rrS2k8XEcZSDPU7EyTBMZvWrQd3abiIuwLQKuLqkTvV gQCIpxpx++F7EN6ziMlZ6dNDyqNrK+1KVqXtWfCOF9MZCyotVT4sJ8vMdRa6lS601W7nA9sMSM7 a3C7I X-Gm-Gg: ASbGnctjz4ze0JG3B3JwMu2O5txKCVDBAyQayBxJt8HFpecjP+eo1Ea1uWxUWw0Gva+ 9bkbIpNvcXlfLnhg9YLwdzixM35C9Il/CwoeckDsBntIFZPLojVpa+ims0bxuKRWhdKzHDg7Fug 8DWpXEbmMRQRGqTwzQLd1AsV4gi8mAm+TUsmFgEhfenlbDmkNX6bAOEWFEHzY1EYplveUg9O2O9 Q2Bz8xMhwfsRSo8XtOawtV3Vw0uyTY4pCs+X0vf0sH9QHgJGNC95MM8TvKtalm8tqXBANExqsLm YAugnXY5d/6p6xyLpXEIt/WtwRkw5e8dnAdxkGJPuSrrN4oDVfr0fatL8eYhiPwp3HSlLvx/Ngb lktc5rBN1eRHBbBVXP+Hkejp/dTo/4btWzROVKU3Fjevw8mcOS+ujg5BC/ZS3TBx0pW+rU2fpA0 vcyXaDNjx+g+v8vaiYkHyNklFEvnL2Qwqu59Ak X-Google-Smtp-Source: AGHT+IHvRpXJtnyiwKLjzZx/ozcRmKCi93mtb3M0cqUPz6Vsa5iPSfTaNpHqBjpIkA+snazfQwc2Tg== X-Received: by 2002:a05:6830:44aa:b0:78a:8b0d:cd54 with SMTP id 46e09a7af769-7c958c06fc3mr950721a34.34.1764815641091; Wed, 03 Dec 2025 18:34:01 -0800 (PST) Received: from shuah-framework.internal ([38.175.187.108]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7c95a8f8d0bsm510833a34.5.2025.12.03.18.33.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Dec 2025 18:34:00 -0800 (PST) From: Shuah Khan To: akpm@linux-foundation.org, david@kernel.org Cc: Shuah Khan , 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 Subject: [PATCH] Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb" Date: Wed, 3 Dec 2025 19:33:56 -0700 Message-ID: <20251204023358.54107-1-skhan@linuxfoundation.org> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This reverts commit 39231e8d6ba7f794b566fd91ebd88c0834a23b98. 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. 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 111= 72790 (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 0002003e951b5057c16de5a39140abcbf6e4= 4e50 fatal: fetch-pack: invalid index-pack output 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/platform= s/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 stru= ct folio *folio) return folio_large_nr_pages(folio); } =20 -#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 st= ruct 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 ex= pect - * 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 =20 -# -# 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 --=20 2.51.0