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 82956C4829F for ; Wed, 14 Feb 2024 07:44:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 927838D0011; Wed, 14 Feb 2024 02:44:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D7868D0001; Wed, 14 Feb 2024 02:44:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79FBE8D0011; Wed, 14 Feb 2024 02:44:09 -0500 (EST) 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 656C58D0001 for ; Wed, 14 Feb 2024 02:44:09 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9EEDD120C38 for ; Wed, 14 Feb 2024 07:44:08 +0000 (UTC) X-FDA: 81789620976.22.47AAA27 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id D915D140015 for ; Wed, 14 Feb 2024 07:44:06 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Gkj581Sl; spf=pass (imf09.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707896647; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=r6iNabMloOVKIxFHuixNntTOnHjAToFM2Ga0pX2EqWQ=; b=Ry0aNM+clzo2S2oyHyoo7HHRlasZzY6VArTCASn3tVRJ8/tUQ9BgBhNyfm0RyZrnG2NhKY g4szXA/vl/rTVH+ma6bNc4QbcDxGFnuCTf1zebS9tQJxeEUNZpnTa4ZgtWg3scrk9S0Qu+ mQktU29pnvThgYzWaho2q70BkzQFtko= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707896647; a=rsa-sha256; cv=none; b=CXaEww2qOe/1N9znule/YxaL/TQRWwYjDd9qIx8wvVjSwhEdClJB/BmSHXCwUXJgOlef07 lB0P7rSFYZuT5sLQGoXMRmM46yUt26bG6hIDXPVA4Iyz/ha1Mr/wjWGY2cBSxoE/a0Qzux hPlqjVksFXRugOiPMAqDiFtDsI2jvYQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Gkj581Sl; spf=pass (imf09.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 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C095B614FF; Wed, 14 Feb 2024 07:44:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45C7EC43390; Wed, 14 Feb 2024 07:44:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707896645; bh=tb1JZh7YjHC54vuRohUqN9Z1NIGc0/Pz/uPDjKWR0AA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Gkj581SlUmdpPMZleIyFmicCmLzpseArp1VO3FbpTvalrb33rZVCKkDHZtuq/nAaf XaAolWXwCCjSX/F7lBpKqtbn+N2s4EueUjdUjvyA6oQR3GrQ2Tz/PWLdkU04LJ6T3x z/CmSTaC74QZYNBwEOWmEX+t852/xRcLGSlPaRwEZyzkiiuJilAuBy33fdEik6xyrC n86DNuYeokTk7Mu7J5wiguwnxbaFQrkj35GRKx4Y4XHEDgV7iKQ5Iy/yj9t0PiRtph yEOzSX0374cLbyBsENoEf07VqfuxQiuQV7pnUBd+VU4pz/W4vDjGWli18+OotbSOyq xAmwFPGgvplqA== Date: Wed, 14 Feb 2024 09:43:38 +0200 From: Mike Rapoport To: "Aiqun Yu (Maria)" Cc: Vijayanand Jitta , Dmitry Baryshkov , Faiyaz Mohammed , karahmed@amazon.de, qperret@google.com, robh@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, frowand.list@gmail.com, devicetree@vger.kernel.org Subject: Re: [PATCH] mm: memblock: avoid to create memmap for memblock nomap regions Message-ID: References: <1649704172-13181-1-git-send-email-quic_faiyazm@quicinc.com> <7b18bea8-b996-601d-f490-cb8aadfffa1b@quicinc.com> <42f28e7b-c001-7d01-1eb6-fe963491898e@quicinc.com> <22aca197-8d18-2c9e-b3c4-f6fdc893ceb1@quicinc.com> <76cb3b37-5887-404f-95b7-10a22a7ba65b@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76cb3b37-5887-404f-95b7-10a22a7ba65b@quicinc.com> X-Stat-Signature: xy3zyyepnf19imof5x7duoxnt4cdizu7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D915D140015 X-Rspam-User: X-HE-Tag: 1707896646-841328 X-HE-Meta: U2FsdGVkX1/fiAzZFdQV1M1ctDjbMHQZJYwQHw9XekY/AEeRtEWRCBrGWCURQhaB0Jy9fCQuS86I+g+cyqZ6oeKYZKGn1dN5LytA6PvwCYFOXmLCapbocQKDZ8U5u8glm7R/WXZC74vuPLH9z9kKqj2qIOQQyCgc1C8+hAyZYLu4FI4cpQ0J8/Hw1Cvc6B9tpEjuey/3rf8HixkhLyr2/ma6JhV1y/xBgN8cTVPnI1+LAQPvY2L6hhj3KiLI1UieR4T7BkpyoiwX4eQsSy13iVMxFa1bQ/e5h0KQHQytN53R5GEmoHKygSgPdnZx7ww/csGYsfj2pQYtlg+Yer3G2gDutRrzRyzgw+PNSUC7Rrxk4tLQ9dqfyJYfR/76OWR+Qhtj9y4FYqnAgE+l1QqY07VJppnCY931i7hghRMeDy+NT+QGu/e1SXx3tHf8VNuxRRy9G5nVbmNgi+9tqchJAIIul9dBL4nmGV8vKkDeWAYoxQqfu+6A3CA91/bhiGNn24l2ibGbRlx9lqmp+AaeanFfxCkwK0ocLszJPfXGGUWAo0NkDu6eO2ESOH6Gdth7Gb0INBCIu926TU+P+0xlCUewzEDE5l3IRcckoFhe2ljbreU/TLp8PHJsSzJymsVtOXcA8shSzXGI17UnGHuoUwbXwLzLigrWRqKdOxKpy5Yzw6l5nzbXlnUC/ERhbicgGt5lLTjNEUot4lvufbKjeHa/C81qA5fq2yI9Xh+owxfH6B2uciBDYgcTEefmYu5nlp4/MBKWFQS/dCyxyXBOsJVLaUuRddtusZg4AdzJ/tz5XpXb1hEghaWphAGMSWU323iacKef+QgLOY7nL13H31bBLvgu7543Du8y25GR2ve+oFVkdERiIkyMD7/p9f531Tn96x0tN7KJrmd1wsx1k7BL03XcU7XVw+ldCdieqKuCeSnzl6MFzeJkD0aqskWDVgAIlmFamuwpLtO0FlG 5Pu9BIQS jtj0E2o9gO7LBZq72H7XKB268t3VElwrAIMHBfhsGOIqCH+jdW3lI+zNgFgCeLjAOWQycHI8sqxa8Plc1+bRNn3+vqXM6uGdz2wckuV728FR2Ss0/cGrM9HSwq9k3S8vkuVidg7IKELXuN/vN5plX52Rtm1Kv2npPpZPANidKFMoTOzfk/JjZz8djx3YkNBZ3sZ43usgAve62KBmsNp9I/9RqMOQn3CbYo2BXmCEjbG0FPLChxu4K+lP6KDX5EX94YJ5TRvVL3pQm8DHKFAJ/ViXaWIrzolTvndX9 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: List-Subscribe: List-Unsubscribe: On Thu, Feb 08, 2024 at 02:37:25PM +0800, Aiqun Yu (Maria) wrote: > > On 8/6/2022 3:22 AM, Mike Rapoport wrote: > > Hi Vijay, > > > > On Wed, Aug 03, 2022 at 04:27:33PM +0530, Vijayanand Jitta wrote: > > > > > > On 5/9/2022 5:12 PM, Mike Rapoport wrote: > > > > On Mon, May 09, 2022 at 04:37:30PM +0530, Faiyaz Mohammed wrote: > > > > > > > > > > On 5/5/2022 10:24 PM, Mike Rapoport wrote: > > > > > > On Thu, May 05, 2022 at 08:46:15PM +0530, Faiyaz Mohammed wrote: > > > > > > > On 4/12/2022 10:56 PM, Mike Rapoport wrote: > > > > > > > > On Tue, Apr 12, 2022 at 12:39:32AM +0530, Faiyaz Mohammed wrote: > > > > > > > > > This 'commit 86588296acbf ("fdt: Properly handle "no-map" field in the > > > > > > > > > memory region")' is keeping the no-map regions in memblock.memory with > > > > > > > > > MEMBLOCK_NOMAP flag set to use no-map memory for EFI using memblock api's, > > > > > > > > > but during the initialization sparse_init mark all memblock.memory as > > > > > > > > > present using for_each_mem_pfn_range, which is creating the memmap for > > > > > > > > > no-map memblock regions. To avoid it skiping the memblock.memory regions > > > > > > > > > set with MEMBLOCK_NOMAP set and with this change we will be able to save > > > > > > > > > ~11MB memory for ~612MB carve out. > > > > > > > > The MEMBLOCK_NOMAP is very fragile and caused a lot of issues already. I > > > > > > > > really don't like the idea if adding more implicit assumptions about how > > > > > > > > NOMAP memory may or may not be used in a generic iterator function. > > > > > > > Sorry for delayed response. > > > > > > > Yes, it is possible that implicit assumption can create > > > > > > > misunderstanding. How about adding command line option and control the > > > > > > > no-map region in fdt.c driver, to decide whether to keep "no-map" region > > > > > > > with NOMAP flag or remove?. Something like below > > > > > > I really don't like memblock_remove() for such cases. > > > > > > Pretending there is a hole when there is an actual DRAM makes things really > > > > > > hairy when it comes to memory map and page allocator initialization. > > > > > > You wouldn't want to trade system stability and random memory corruptions > > > > > > for 11M of "saved" memory. > > > > > > > > > > Creating memory map for holes memory is adding 11MB overhead which is > > > > > huge on low memory target and same time 11MB memory saving is good enough > > > > > on low memory target. > > > > > > > > > > Or we can have separate list of NOMAP like reserved?. > > > > > > > > > > Any other suggestion to address this issue?. > > > > > > > > Make your firmware to report the memory that Linux cannot use as a hole, > > > > i.e. _not_ report it as memory. > > > > > > Thanks, Mike for the comments. > > > > > > Few concerns with this approach. > > > > > > 1) One concern is, even if firmware doesn't report these regions as > > > memory, we would need addresses for these to be part of device tree so > > > that the clients would be able to get these addresses. Otherwise there > > > is no way for client to know these addresses. > > > > > > 2) This would also add a dependency on firmware to be able to pass these > > > regions not as memory, though we know that these regions would be used > > > by the clients. Isn't it better to have such control within the kernel ? > > > > If it is memory that is used by the kernel it should be reported as memory > > and have the memory map. > > If this is a hole in the memory layout from the kernel perspective, then > > kernel should not bother with this memory. > Hi Mike, > > We've put effort on bootloader side to implement the similar suggestion of > os bootloader to convey the reserved memory by omit the hole from > /memory@0{reg=[]} directly. > While there is a concern from device tree spec perspective, link [1]: "A > memory device node is required for all devicetrees and describes the > physical memory layout for the system. " > Do you have any idea on this pls? I'm not sure I understand your concern. Isn't there a /memory node that describes the memory available to Linux in your devicetree? > [1] https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter3-devicenodes.rst > > > > And I'm not buying "low memory target" argument if you have enough memory > > to carve out ~600M for some mysterious clients. > > Just for your information, for low memory target, the carve out can be more > than ~60M out of 128M in total. If saving ~1M of memory map is important, hide the carve out from Linux entirely. > > > Let me know your comments on these. > > > > > > Thanks, > > > Vijay > > -- > Thx and BRs, > Aiqun(Maria) Yu -- Sincerely yours, Mike.