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 4803921322F for ; Mon, 17 Nov 2025 11:23:42 +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=1763378623; cv=none; b=SVf+nKaDxi+pQtgh/NR8EUeN+s8pgLKnxeBzQnkgRZYCUqwxDZBp/Pz11ec+oAyG92Z+nKL5EUAY7eeAoPoe5j6nHaLmoXFhUHNhe5O4BPUbNXFaAqk4J41LGal6x1ZrcnYIEwPLojnoTCAvf891kRsDw4h6MTIDdWvwYFZbhO4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763378623; c=relaxed/simple; bh=AS2LOdZB9mGe8g+PTF2d3HZ0vp9cklG1f8pIgTQRq+Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gEnw9Vr/cxnQd8gPauGrHr+2Sf7Jc/F2OBWqqHdIwlihHrEXiebu+MHVsaDQKOJi3Eu9j0XJdYB5SMS1xncFtaPZRXuBXOfXZvoMOhrlweD01fKMV1rC6AOaO73KajuCFTZdE8H0XSYD4i1T1zbDxoAzW7Kka2QVO3D/5+9vmgM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mI2M+SGs; 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="mI2M+SGs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1272C4CEF1; Mon, 17 Nov 2025 11:23:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763378622; bh=AS2LOdZB9mGe8g+PTF2d3HZ0vp9cklG1f8pIgTQRq+Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=mI2M+SGsm9caH86sXqrWFYAILM/5jD96wHWRsWaZ9Y/ikSIoYC5zTmEouwBUzllC0 TZgKQQ3QNY7ALqjO9/QbMJTNt8+IrF6Wp1sVZToAcy/IX6QhaMzLwFbC2k19OnWDc1 NkBJ7t5o4AlfQysgofzrrF7tBUtdjZOjWivHCDSqjjyP+MDomvSNsYVA9I1AHQt4ak DVNXsdg1SKU8oLcMTKyOFkh5oCAyoUjziAuunPJLyFaeKfUVAaben8Kf6slF78d3NO FYCpLpmF1MFK67/xcRRQVTLIbG0sX8jPQj2U+NCuVYy46g+ux4eANLg+MrxwJDVqzp Utx3AI8iCMu2g== Message-ID: <4b81bc10-59a0-4ff2-99db-12dc7157da85@kernel.org> Date: Mon, 17 Nov 2025 12:23:35 +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: Christophe Leroy , 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: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 15.11.25 10:37, Christophe Leroy wrote: > > > 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 Thanks a lot for the review and test! (thanks to the other reviewers obviously as well :) ) -- Cheers David