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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76405C43334 for ; Fri, 3 Jun 2022 10:54:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEAA18D0002; Fri, 3 Jun 2022 06:54:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D96B48D0001; Fri, 3 Jun 2022 06:54:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5C1F8D0002; Fri, 3 Jun 2022 06:54:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B126C8D0001 for ; Fri, 3 Jun 2022 06:54:44 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7DCC9210BD for ; Fri, 3 Jun 2022 10:54:44 +0000 (UTC) X-FDA: 79536616488.04.B25F883 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf31.hostedemail.com (Postfix) with ESMTP id 2A02320083 for ; Fri, 3 Jun 2022 10:54:01 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2FF341063; Fri, 3 Jun 2022 03:54:43 -0700 (PDT) Received: from [10.162.42.23] (unknown [10.162.42.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 583A03F73D; Fri, 3 Jun 2022 03:54:40 -0700 (PDT) Message-ID: Date: Fri, 3 Jun 2022 16:24:37 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v2] arm64: Expand the static memblock memory table Content-Language: en-US To: "Zhouguanghui (OS Kernel)" , "akpm@linux-foundation.org" , "rppt@kernel.org" , "will@kernel.org" Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "xuqiang (M)" References: <20220517114309.10228-1-zhouguanghui1@huawei.com> <5d9390e36e6148e49284af3a7233accb@huawei.com> From: Anshuman Khandual In-Reply-To: <5d9390e36e6148e49284af3a7233accb@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 2A02320083 X-Stat-Signature: nrtcyhcedpmx41eexz5fdc5eef14fxs3 X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf31.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com X-Rspamd-Server: rspam08 X-HE-Tag: 1654253641-645446 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/27/22 14:26, Zhouguanghui (OS Kernel) wrote: > Hi Anshuman, > > 在 2022/5/18 12:40, Anshuman Khandual 写道: >> Hi Zhou, >> >> A small nit. >> >> This changes generic memblock to accommodate arm64 specific scenario. >> Keeping the subject line as 'mm/memblock: ...' might be better. >> > > I will add memblock to the subject line. > >> On 5/17/22 17:13, Zhou Guanghui wrote: >>> In a system using HBM, a multi-bit ECC error occurs, and the BIOS >>> saves the corresponding area (for example, 2 MB). When the system >>> restarts next time, these areas are isolated and not reported or >>> reported as EFI_UNUSABLE_MEMORY. Both of them lead to an increase >> >> Which cases dont get reported rather than as EFI_UNUSABLE_MEMORY ? Is >> this supported on arm64 platform via mainline kernel ? >> > > The BIOS determines how to report the memory area that cannot be used to > the kernel. Do not report the memory area to the kernel or inform the > kernel that the memory area is unusable. Right, but just curious whether there are real systems in the field with this feature running mainline kernel ? OR this is just being future proof. > >>> in the number of memblocks, whereas EFI_UNUSABLE_MEMORY leads to >>> a larger number of memblocks. >>> >>> For example, if the EFI_UNUSABLE_MEMORY type is reported: >>> ... >>> memory[0x92] [0x0000200834a00000-0x0000200835bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0 >>> memory[0x93] [0x0000200835c00000-0x0000200835dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4 >>> memory[0x94] [0x0000200835e00000-0x00002008367fffff], 0x0000000000a00000 bytes on node 7 flags: 0x0 >>> memory[0x95] [0x0000200836800000-0x00002008369fffff], 0x0000000000200000 bytes on node 7 flags: 0x4 >>> memory[0x96] [0x0000200836a00000-0x0000200837bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0 >>> memory[0x97] [0x0000200837c00000-0x0000200837dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4 >>> memory[0x98] [0x0000200837e00000-0x000020087fffffff], 0x0000000048200000 bytes on node 7 flags: 0x0 >>> memory[0x99] [0x0000200880000000-0x0000200bcfffffff], 0x0000000350000000 bytes on node 6 flags: 0x0 >>> memory[0x9a] [0x0000200bd0000000-0x0000200bd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4 >>> memory[0x9b] [0x0000200bd0200000-0x0000200bd07fffff], 0x0000000000600000 bytes on node 6 flags: 0x0 >>> memory[0x9c] [0x0000200bd0800000-0x0000200bd09fffff], 0x0000000000200000 bytes on node 6 flags: 0x4 >>> memory[0x9d] [0x0000200bd0a00000-0x0000200fcfffffff], 0x00000003ff600000 bytes on node 6 flags: 0x0 >>> memory[0x9e] [0x0000200fd0000000-0x0000200fd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4 >>> memory[0x9f] [0x0000200fd0200000-0x0000200fffffffff], 0x000000002fe00000 bytes on node 6 flags: 0x0 >> >> Got it. >> >>> ... >>> >>> If the size of the init memblock regions is exceeded before the >>> array size can be resized, the excess memory will be lost. >> >> Could you please elaborate more on why additional memblock regions can >> not be accommodated via memblock array resizing ? >> > > As described in the memblock_double_array function: We don't allow > resizing until we know about the reserved regions of memory that aren' > not suitable for allocation. > >>> >>> Signed-off-by: Zhou Guanghui >>> --- >>> arch/arm64/include/asm/memory.h | 9 +++++++++ >>> mm/memblock.c | 14 +++++++++----- >>> 2 files changed, 18 insertions(+), 5 deletions(-) >>> >>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h >>> index 0af70d9abede..eda61c0389c4 100644 >>> --- a/arch/arm64/include/asm/memory.h >>> +++ b/arch/arm64/include/asm/memory.h >>> @@ -364,6 +364,15 @@ void dump_mem_limit(void); >>> # define INIT_MEMBLOCK_RESERVED_REGIONS (INIT_MEMBLOCK_REGIONS + NR_CPUS + 1) >>> #endif >>> >>> +/* >>> + * memory regions which marked with flag MEMBLOCK_NOMAP may divide a continuous >>> + * memory block into multiple parts. As a result, the number of memory regions >>> + * is large. >>> + */ >>> +#ifdef CONFIG_EFI >> >> Could not memblock regions tagged with MEMBLOCK_NOMAP flag not present >> on non-EFI systems ? Just wondering, are there not some other scenarios >> which will also require expanded static memblock array. > > Systems using devicetree can also have "no-map" memory. However, in this > case, the expanded static memblock array is required only when a large > number of such no-map reserved memories are manually added. I don't know > if any users will do that. > > Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > > As to whether other scenarios also require expanded static memblock > arrays, I really don't know. In that case could this comment here be more specific about this increased static array size, being applicable only for MEMBLOCK_NOMAP regions on EFI system with EFI_UNUSABLE_MEMORY tagging support. Is there an way to narrow this down further wrt EFI_UNUSABLE_MEMORY, rather than blanket EFI ? +/* + * memory regions which marked with flag MEMBLOCK_NOMAP may divide a continuous + * memory block into multiple parts. As a result, the number of memory regions + * is large. + */ +#ifdef CONFIG_EFI +#define INIT_MEMBLOCK_MEMORY_REGIONS 1024 +#endif + > >> >>> +#define INIT_MEMBLOCK_MEMORY_REGIONS 1024 >>> +#endif >>> + >>> #include >>> >>> #endif /* __ASM_MEMORY_H */ >>> diff --git a/mm/memblock.c b/mm/memblock.c >>> index e4f03a6e8e56..7c63571a69d7 100644 >>> --- a/mm/memblock.c >>> +++ b/mm/memblock.c >>> @@ -29,6 +29,10 @@ >>> # define INIT_MEMBLOCK_RESERVED_REGIONS INIT_MEMBLOCK_REGIONS >>> #endif >>> >>> +#ifndef INIT_MEMBLOCK_MEMORY_REGIONS >>> +#define INIT_MEMBLOCK_MEMORY_REGIONS INIT_MEMBLOCK_REGIONS >>> +#endif >> >> Why create an additional macro INIT_MEMBLOCK_MEMORY_REGIONS ? Why cannot >> INIT_MEMBLOCK_REGIONS be defined in the platform directly like the other >> macro INIT_MEMBLOCK_RESERVED_REGIONS ? >> > > The number of reserved memblocks does not need to be increased. Got it.