From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5D6FC433E6 for ; Thu, 21 Jan 2021 14:18:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 56871239FC for ; Thu, 21 Jan 2021 14:18:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730551AbhAUOSI (ORCPT ); Thu, 21 Jan 2021 09:18:08 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:6040 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728970AbhAUORN (ORCPT ); Thu, 21 Jan 2021 09:17:13 -0500 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 10LECCdm146756; Thu, 21 Jan 2021 09:16:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=LgIyQwq1hR6kmioYSRjLoABMPgvbuBjTa3lrYLfCtQ4=; b=fJwfGmHefCX3FmP6wIV3ex21TX9Na1Q9XENeaHgy1FpUtIs5J6QN9mI7LtR1+3EDr57t kdWH9aCeExw00mCIDLIBfM9yXL594itZfSSGX5HZDFPQ8r50WaWTNSx6NPBDJV3nFMY8 VICDVVty9yQpn94cRviYncLgZiev+R1gr+cWepB/V4E/VVST/l54gYvRBUUg90+DOd5X OAoB2bB6OXgSDqMnswoHt6mfKUTRxHN2fn03SwnehULfTn1LqPZSvoXud7Ltqu7JlWNE WkAlE01bW1PBaYGp9J22faE9++Hpcg6pidlpActLL7Clisny3yIzGHbjxIjtRcNL0EPS hw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 367b5mg32b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 09:16:17 -0500 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 10LEFv9N163729; Thu, 21 Jan 2021 09:16:17 -0500 Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 367b5mg304-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 09:16:16 -0500 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 10LEE1FD024969; Thu, 21 Jan 2021 14:16:13 GMT Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by ppma03fra.de.ibm.com with ESMTP id 3668ny0w57-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 14:16:13 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 10LEGBsv43188588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Jan 2021 14:16:11 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 14A3611C04C; Thu, 21 Jan 2021 14:16:11 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B63111C050; Thu, 21 Jan 2021 14:16:09 +0000 (GMT) Received: from linux.ibm.com (unknown [9.145.173.122]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 21 Jan 2021 14:16:09 +0000 (GMT) Date: Thu, 21 Jan 2021 16:16:07 +0200 From: Mike Rapoport To: Sudarshan Rajagopalan Cc: linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Anshuman Khandual , David Hildenbrand , Mark Rutland , Logan Gunthorpe , Andrew Morton , Steven Price , Suren Baghdasaryan Subject: Re: [PATCH 1/1] arm64/sparsemem: reduce SECTION_SIZE_BITS Message-ID: <20210121141607.GB7648@linux.ibm.com> References: <43843c5e092bfe3ec4c41e3c8c78a7ee35b69bb0.1611206601.git.sudaraja@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43843c5e092bfe3ec4c41e3c8c78a7ee35b69bb0.1611206601.git.sudaraja@codeaurora.org> X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343,18.0.737 definitions=2021-01-21_06:2021-01-21,2021-01-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 adultscore=0 clxscore=1011 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 malwarescore=0 priorityscore=1501 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101210074 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 20, 2021 at 09:29:13PM -0800, Sudarshan Rajagopalan wrote: > memory_block_size_bytes() determines the memory hotplug granularity i.e the > amount of memory which can be hot added or hot removed from the kernel. The > generic value here being MIN_MEMORY_BLOCK_SIZE (1UL << SECTION_SIZE_BITS) > for memory_block_size_bytes() on platforms like arm64 that does not override. > > Current SECTION_SIZE_BITS is 30 i.e 1GB which is large and a reduction here > increases memory hotplug granularity, thus improving its agility. A reduced > section size also reduces memory wastage in vmemmmap mapping for sections > with large memory holes. So we try to set the least section size as possible. > > A section size bits selection must follow: > (MAX_ORDER - 1 + PAGE_SHIFT) <= SECTION_SIZE_BITS > > CONFIG_FORCE_MAX_ZONEORDER is always defined on arm64 and so just following it > would help achieve the smallest section size. > > SECTION_SIZE_BITS = (CONFIG_FORCE_MAX_ZONEORDER - 1 + PAGE_SHIFT) > > SECTION_SIZE_BITS = 22 (11 - 1 + 12) i.e 4MB for 4K pages > SECTION_SIZE_BITS = 24 (11 - 1 + 14) i.e 16MB for 16K pages without THP > SECTION_SIZE_BITS = 25 (12 - 1 + 14) i.e 32MB for 16K pages with THP > SECTION_SIZE_BITS = 26 (11 - 1 + 16) i.e 64MB for 64K pages without THP > SECTION_SIZE_BITS = 29 (14 - 1 + 16) i.e 512MB for 64K pages with THP > > But there are other problems in reducing SECTION_SIZE_BIT. Reducing it by too > much would over populate /sys/devices/system/memory/ and also consume too many > page->flags bits in the !vmemmap case. Also section size needs to be multiple > of 128MB to have PMD based vmemmap mapping with CONFIG_ARM64_4K_PAGES. > > Given these constraints, lets just reduce the section size to 128MB for 4K > and 16K base page size configs, and to 512MB for 64K base page size config. > > Signed-off-by: Sudarshan Rajagopalan > Suggested-by: Anshuman Khandual > Suggested-by: David Hildenbrand > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Anshuman Khandual > Cc: David Hildenbrand > Cc: Mike Rapoport > Cc: Mark Rutland > Cc: Logan Gunthorpe > Cc: Andrew Morton > Cc: Steven Price > Cc: Suren Baghdasaryan Acked-by: Mike Rapoport BTW, after reduction of the section size maybe arm64 should consider opting out of freeing unused memory map. This will make David even more happy as this will allow dropping custom pfn_valid() ;-) > --- > arch/arm64/include/asm/sparsemem.h | 23 +++++++++++++++++++++-- > 1 file changed, 21 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h > index 1f43fcc79738..eb4a75d720ed 100644 > --- a/arch/arm64/include/asm/sparsemem.h > +++ b/arch/arm64/include/asm/sparsemem.h > @@ -7,7 +7,26 @@ > > #ifdef CONFIG_SPARSEMEM > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > -#define SECTION_SIZE_BITS 30 > -#endif > + > +/* > + * Section size must be at least 512MB for 64K base > + * page size config. Otherwise it will be less than > + * (MAX_ORDER - 1) and the build process will fail. > + */ > +#ifdef CONFIG_ARM64_64K_PAGES > +#define SECTION_SIZE_BITS 29 > + > +#else > + > +/* > + * Section size must be at least 128MB for 4K base > + * page size config. Otherwise PMD based huge page > + * entries could not be created for vmemmap mappings. > + * 16K follows 4K for simplicity. > + */ > +#define SECTION_SIZE_BITS 27 > +#endif /* CONFIG_ARM64_64K_PAGES */ > + > +#endif /* CONFIG_SPARSEMEM*/ > > #endif > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8E63C433E6 for ; Thu, 21 Jan 2021 14:18:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4EB93239D1 for ; Thu, 21 Jan 2021 14:18:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EB93239D1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=EDAGmA1WiAl2FNhh0CkSgYPeKVgX2mFd0pI6hQ4Mhwc=; b=BJRaIa9sz1QtYOMZy5cOw8rNp X/5dc3DIdebLtDs7K6NGO3W90yHvfe6HuOyVToljSw9O8jOv1LY/U96u4v/kbE0QmXqBV71eMEPuk 789tbwUQ9ycN+kjCOUcZiulgT5AhR6ARyNlyHViw4LH8Vc84+qZyKDgCHPNbzMb/8iB0U/HVcmyXt LQrjTpHaUR/xeUPDlNCfjApLWF9Mfizc5sV/FoV+HhEVSekdGkLV0um8Jj5dqf596/RzXnQo1vysk 2WafUza/uavIiQnmID4v6xUZTqnSQZmnJK6Xx7cbWiAY0aDVFu1gx+qpe9oEJiaVAHdt0YZ2WgI5r WVzZQ+bCQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2alG-0005N6-7Q; Thu, 21 Jan 2021 14:16:34 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2alD-0005MP-Ig for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 14:16:32 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 10LECCdm146756; Thu, 21 Jan 2021 09:16:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=LgIyQwq1hR6kmioYSRjLoABMPgvbuBjTa3lrYLfCtQ4=; b=fJwfGmHefCX3FmP6wIV3ex21TX9Na1Q9XENeaHgy1FpUtIs5J6QN9mI7LtR1+3EDr57t kdWH9aCeExw00mCIDLIBfM9yXL594itZfSSGX5HZDFPQ8r50WaWTNSx6NPBDJV3nFMY8 VICDVVty9yQpn94cRviYncLgZiev+R1gr+cWepB/V4E/VVST/l54gYvRBUUg90+DOd5X OAoB2bB6OXgSDqMnswoHt6mfKUTRxHN2fn03SwnehULfTn1LqPZSvoXud7Ltqu7JlWNE WkAlE01bW1PBaYGp9J22faE9++Hpcg6pidlpActLL7Clisny3yIzGHbjxIjtRcNL0EPS hw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 367b5mg32b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 09:16:17 -0500 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 10LEFv9N163729; Thu, 21 Jan 2021 09:16:17 -0500 Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 367b5mg304-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 09:16:16 -0500 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 10LEE1FD024969; Thu, 21 Jan 2021 14:16:13 GMT Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by ppma03fra.de.ibm.com with ESMTP id 3668ny0w57-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 14:16:13 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 10LEGBsv43188588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Jan 2021 14:16:11 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 14A3611C04C; Thu, 21 Jan 2021 14:16:11 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B63111C050; Thu, 21 Jan 2021 14:16:09 +0000 (GMT) Received: from linux.ibm.com (unknown [9.145.173.122]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 21 Jan 2021 14:16:09 +0000 (GMT) Date: Thu, 21 Jan 2021 16:16:07 +0200 From: Mike Rapoport To: Sudarshan Rajagopalan Subject: Re: [PATCH 1/1] arm64/sparsemem: reduce SECTION_SIZE_BITS Message-ID: <20210121141607.GB7648@linux.ibm.com> References: <43843c5e092bfe3ec4c41e3c8c78a7ee35b69bb0.1611206601.git.sudaraja@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <43843c5e092bfe3ec4c41e3c8c78a7ee35b69bb0.1611206601.git.sudaraja@codeaurora.org> X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-21_06:2021-01-21, 2021-01-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 adultscore=0 clxscore=1011 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 malwarescore=0 priorityscore=1501 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101210074 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_091631_744977_2B3B8641 X-CRM114-Status: GOOD ( 33.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Anshuman Khandual , Catalin Marinas , David Hildenbrand , linux-kernel@vger.kernel.org, Steven Price , Suren Baghdasaryan , linux-mm@kvack.org, Logan Gunthorpe , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 20, 2021 at 09:29:13PM -0800, Sudarshan Rajagopalan wrote: > memory_block_size_bytes() determines the memory hotplug granularity i.e the > amount of memory which can be hot added or hot removed from the kernel. The > generic value here being MIN_MEMORY_BLOCK_SIZE (1UL << SECTION_SIZE_BITS) > for memory_block_size_bytes() on platforms like arm64 that does not override. > > Current SECTION_SIZE_BITS is 30 i.e 1GB which is large and a reduction here > increases memory hotplug granularity, thus improving its agility. A reduced > section size also reduces memory wastage in vmemmmap mapping for sections > with large memory holes. So we try to set the least section size as possible. > > A section size bits selection must follow: > (MAX_ORDER - 1 + PAGE_SHIFT) <= SECTION_SIZE_BITS > > CONFIG_FORCE_MAX_ZONEORDER is always defined on arm64 and so just following it > would help achieve the smallest section size. > > SECTION_SIZE_BITS = (CONFIG_FORCE_MAX_ZONEORDER - 1 + PAGE_SHIFT) > > SECTION_SIZE_BITS = 22 (11 - 1 + 12) i.e 4MB for 4K pages > SECTION_SIZE_BITS = 24 (11 - 1 + 14) i.e 16MB for 16K pages without THP > SECTION_SIZE_BITS = 25 (12 - 1 + 14) i.e 32MB for 16K pages with THP > SECTION_SIZE_BITS = 26 (11 - 1 + 16) i.e 64MB for 64K pages without THP > SECTION_SIZE_BITS = 29 (14 - 1 + 16) i.e 512MB for 64K pages with THP > > But there are other problems in reducing SECTION_SIZE_BIT. Reducing it by too > much would over populate /sys/devices/system/memory/ and also consume too many > page->flags bits in the !vmemmap case. Also section size needs to be multiple > of 128MB to have PMD based vmemmap mapping with CONFIG_ARM64_4K_PAGES. > > Given these constraints, lets just reduce the section size to 128MB for 4K > and 16K base page size configs, and to 512MB for 64K base page size config. > > Signed-off-by: Sudarshan Rajagopalan > Suggested-by: Anshuman Khandual > Suggested-by: David Hildenbrand > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Anshuman Khandual > Cc: David Hildenbrand > Cc: Mike Rapoport > Cc: Mark Rutland > Cc: Logan Gunthorpe > Cc: Andrew Morton > Cc: Steven Price > Cc: Suren Baghdasaryan Acked-by: Mike Rapoport BTW, after reduction of the section size maybe arm64 should consider opting out of freeing unused memory map. This will make David even more happy as this will allow dropping custom pfn_valid() ;-) > --- > arch/arm64/include/asm/sparsemem.h | 23 +++++++++++++++++++++-- > 1 file changed, 21 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h > index 1f43fcc79738..eb4a75d720ed 100644 > --- a/arch/arm64/include/asm/sparsemem.h > +++ b/arch/arm64/include/asm/sparsemem.h > @@ -7,7 +7,26 @@ > > #ifdef CONFIG_SPARSEMEM > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > -#define SECTION_SIZE_BITS 30 > -#endif > + > +/* > + * Section size must be at least 512MB for 64K base > + * page size config. Otherwise it will be less than > + * (MAX_ORDER - 1) and the build process will fail. > + */ > +#ifdef CONFIG_ARM64_64K_PAGES > +#define SECTION_SIZE_BITS 29 > + > +#else > + > +/* > + * Section size must be at least 128MB for 4K base > + * page size config. Otherwise PMD based huge page > + * entries could not be created for vmemmap mappings. > + * 16K follows 4K for simplicity. > + */ > +#define SECTION_SIZE_BITS 27 > +#endif /* CONFIG_ARM64_64K_PAGES */ > + > +#endif /* CONFIG_SPARSEMEM*/ > > #endif > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel