From nobody Fri Dec 19 21:49:29 2025 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 D5EFD23A9 for ; Tue, 21 Jan 2025 15:05:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737471924; cv=none; b=EeZbLtlZwXu3oUaEPlzoZ43x6cHGBlfQSDOgEGmhX5QLuYeSamg8chpMCpeQ1MX1z0MPdcM4qSdmcX4x+ddUQoIlwdAP+J5PLSSqN8XEazfiK2r2Kf8bwJBZBIH6Jsz7hmU3DX/D3ngEGyA4qdm72tJRcY8s/hN4Rs4HGlISsGo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737471924; c=relaxed/simple; bh=ZMoL3imff5PQlMZxxoARmppnrhZWN9O+2a9Q9QlVK1o=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=AiRutzfZuh5Jsakv9+J9hV8Gj5/XP+3j2XrsSkT7y5VsrKTCP/UJfN07MABsA8w//VhMO6CwMpbDH1j9+JhqPtgm0QNg8FDHR8XohqI2DhjG+u42H6KKh1FSIyoFiOT0i6CuAbs/wV1adGz0IvaGAtnDNmXTi+4kqn7C8+18Lw8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=mthAQY4+; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="mthAQY4+" Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50LDJKEi003049; Tue, 21 Jan 2025 15:04:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:message-id:mime-version :subject:to; s=pp1; bh=0WHdHb6F/UdUkGp/zgeU43qqnF+ZgyA8tTBJiib4Y 5E=; b=mthAQY4+1lxPsoCGSEykXMvMfgwTCbndnXV4EVtNUmCCmdHnu8+BEaWoY b4fXI9DiQ7hGHPq+iA5uzTvarWQ1Bsb6L2yzV0cwsGlCGEBC/+4tDoCv0g0Vs6HF SMbr6FOTxCgDSMgzZVYqxpCw0fAsKZaWuo9yGTkln5jAoU74opxFxkCjVSbUP8zX f0sPiJo/0t/8WRMM0XXq67tnkPaMGe+5f8tMCwBK7z8xdmWhlPebOHMS3RxMWii/ YuDTcvpefjkf+Zi3kq/Frnc2Rj292PD3huqUO2KXoqYYdye893+qJQchmoKQpc6M KP7y5gwuZjg1QtPyznk3L95L4VPTQ== Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 44a2dyb80r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2025 15:04:42 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 50LD9Z8b019223; Tue, 21 Jan 2025 15:04:41 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 448pmsbugn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2025 15:04:41 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 50LF4aJq57672080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jan 2025 15:04:37 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DFFF820043; Tue, 21 Jan 2025 15:04:36 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F0CF20040; Tue, 21 Jan 2025 15:04:33 +0000 (GMT) Received: from li-4f5ba44c-27d4-11b2-a85c-a08f5b49eada.ibm.com.com (unknown [9.43.54.128]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 21 Jan 2025 15:04:32 +0000 (GMT) From: Sourabh Jain To: akpm@linux-foundation.org Cc: Sourabh Jain , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Heiko Carstens , Vasily Gorbik , Muchun Song , Madhavan Srinivasan , Michael Ellerman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: [PATCH] mm/hugetlb: bring gigantic page allocation under hugepages_supported() Date: Tue, 21 Jan 2025 20:34:19 +0530 Message-ID: <20250121150419.1342794-1-sourabhjain@linux.ibm.com> X-Mailer: git-send-email 2.47.1 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 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: waNMvQVPCRQmQ47C0vVOdm-GXBHxCt8K X-Proofpoint-ORIG-GUID: waNMvQVPCRQmQ47C0vVOdm-GXBHxCt8K X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-01-21_06,2025-01-21_03,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 clxscore=1011 mlxscore=0 phishscore=0 impostorscore=0 priorityscore=1501 malwarescore=0 adultscore=0 mlxlogscore=921 spamscore=0 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501210122 Content-Type: text/plain; charset="utf-8" Despite having kernel arguments to enable gigantic hugepages, this provides a way for the architecture to disable gigantic hugepages on the fly, similar to what we do for hugepages. Components like fadump (PowerPC-specific) need this functionality to disable gigantic hugepages when the kernel is booted solely to collect the kernel core dump. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Muchun Song Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Sourabh Jain --- To evaluate the impact of this change on architectures other than PowerPC, I did the following analysis: For architectures where hugepages_supported() is not redefined, it depends on HPAGE_SHIFT, which is found to be a constant. It is mostly initialized to PMD_SHIFT. Architecture : HPAGE_SHIFT initialized with ARC: PMD_SHIFT (constant) ARM: PMD_SHIFT (constant) ARM64: PMD_SHIFT (constant) Hexagon: 22 (constant) LoongArch: (PAGE_SHIFT + PAGE_SHIFT - 3) (appears to be constant) MIPS: (PAGE_SHIFT + PAGE_SHIFT - 3) (appears to be constant) PARISC: PMD_SHIFT (appears to be constant) RISC-V: PMD_SHIFT (constant) SH: 16 | 18 | 20 | 22 | 26 (constant) SPARC: 23 (constant) So seems like this change shouldn't have any impact on above architectures. On the S390 and X86 architectures, hugepages_supported() is redefined, and I am uncertain at what point it is safe to call hugepages_supported(). --- mm/hugetlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index cec4b121193f..48b42b8d26b4 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4629,7 +4629,7 @@ static int __init hugepages_setup(char *s) * But we need to allocate gigantic hstates here early to still * use the bootmem allocator. */ - if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate)) + if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate) && hugepages_= supported()) hugetlb_hstate_alloc_pages(parsed_hstate); =20 last_mhp =3D mhp; --=20 2.47.1