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 E31CDC433EF for ; Wed, 11 May 2022 06:03:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3275C6B0078; Wed, 11 May 2022 02:03:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D6AC6B007B; Wed, 11 May 2022 02:03:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19D568D0001; Wed, 11 May 2022 02:03:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 09D386B0078 for ; Wed, 11 May 2022 02:03:13 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CF8C832950 for ; Wed, 11 May 2022 06:03:12 +0000 (UTC) X-FDA: 79452419424.31.54A95C0 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 341FC1C00AE for ; Wed, 11 May 2022 06:03:03 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4B80B61719; Wed, 11 May 2022 06:03:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A9E4C385A7; Wed, 11 May 2022 06:03:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652248990; bh=yc7vI9T4PqmCjEjPxZdewSq59ZzcuUXZdKb7+F9lFwc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NZtQaV8pYpvmoRaaSVPezLtcBQGQ/DuPZriA/HqQA9nFocV3fJ9usZ4XDQkRml5/b VNfol2B04Q1NcBIOC+ZSm2i1+TZS+aVZzHxcZ3tVzGWWlyDrIB5LWRaD9Y2TKFL50P q3fvyOv86do4b81MNDZhVCdaQ0H/Me+CvugCKEu3W3lg65Kwb61yR/ZoCZhHa/VhPE +UMq7RAgWr2d+DEFMIUqaENN69QsVlQZrCiJT9MrrRpRdPCZ12A6QZjssmel3Uzt4S AdZuLmJoOVCpQ1oTJ4cv8bFHJALbC26pnM5sHxFo4y62xqLu2zY7rp2f5Pm4l1P+Dt +78LziYV3isrg== Date: Wed, 11 May 2022 09:03:02 +0300 From: Mike Rapoport To: Andrew Morton Cc: Zhou Guanghui , linux-kernel@vger.kernel.org, linux-mm@kvack.org, xuqiang36@huawei.com Subject: Re: [PATCH] memblock: config the number of init memblock regions Message-ID: References: <20220511010530.60962-1-zhouguanghui1@huawei.com> <20220510185523.3f7479b8ffc49a8a7c17d328@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220510185523.3f7479b8ffc49a8a7c17d328@linux-foundation.org> Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NZtQaV8p; spf=pass (imf20.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 341FC1C00AE X-Stat-Signature: fjitu611cpin7kfrxektq61jqonszxjc X-HE-Tag: 1652248983-196022 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 Tue, May 10, 2022 at 06:55:23PM -0700, Andrew Morton wrote: > On Wed, 11 May 2022 01:05:30 +0000 Zhou Guanghui wrote: > > > During early boot, the number of memblocks may exceed 128(some memory > > areas are not reported to the kernel due to test failures. As a result, > > contiguous memory is divided into multiple parts for reporting). If > > the size of the init memblock regions is exceeded before the array size > > can be resized, the excess memory will be lost. I'd like to see more details about how firmware creates that sparse memory map in the changelog. > > > > ... > > > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -89,6 +89,14 @@ config SPARSEMEM_VMEMMAP > > pfn_to_page and page_to_pfn operations. This is the most > > efficient option when sufficient kernel resources are available. > > > > +config MEMBLOCK_INIT_REGIONS > > + int "Number of init memblock regions" > > + range 128 1024 > > + default 128 > > + help > > + The number of init memblock regions which used to track "memory" and > > + "reserved" memblocks during early boot. > > + > > config HAVE_MEMBLOCK_PHYS_MAP > > bool > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > index e4f03a6e8e56..6893d26b750e 100644 > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -22,7 +22,7 @@ > > > > #include "internal.h" > > > > -#define INIT_MEMBLOCK_REGIONS 128 > > +#define INIT_MEMBLOCK_REGIONS CONFIG_MEMBLOCK_INIT_REGIONS > > Consistent naming would be nice - MEMBLOCK_INIT versus INIT_MEMBLOCK. > > Can we simply increase INIT_MEMBLOCK_REGIONS to 1024 and avoid the > config option? It appears that the overhead from this would be 60kB or > so. 60k is not big, but using 1024 entries array for 2-4 memory banks on systems that don't report that fragmented memory map is really a waste. We can make this per platform opt-in, like INIT_MEMBLOCK_RESERVED_REGIONS ... > Or zero if CONFIG_ARCH_KEEP_MEMBLOCK and CONFIG_MEMORY_HOTPLUG > are cooperating. ... or add code that will discard unused parts of memblock arrays even if CONFIG_ARCH_KEEP_MEMBLOCK=y. -- Sincerely yours, Mike.