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 B507FC433EF for ; Mon, 9 May 2022 11:42:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 06C916B0071; Mon, 9 May 2022 07:42:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 01B686B0073; Mon, 9 May 2022 07:42:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFDDF6B0074; Mon, 9 May 2022 07:42:55 -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 CB0CE6B0071 for ; Mon, 9 May 2022 07:42:55 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A2F4A3020B for ; Mon, 9 May 2022 11:42:55 +0000 (UTC) X-FDA: 79446017910.20.DA4F754 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id A53E1140085 for ; Mon, 9 May 2022 11:42:42 +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 327B4611B0; Mon, 9 May 2022 11:42:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ACE7CC385AB; Mon, 9 May 2022 11:42:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652096573; bh=ZHVW1u+tmMm1OePaD1hQg53R3eo5Soz0csO+AKlva6Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NQ5sYu1MW3dElVyiqPBxMNJ4DwA1qxHZHk2yMsA++2XBpl3RA+Iwbx5dZpMaFHpMq LlVJRBsNzTlexkRIkx8mXgZOEka3ruacf2oJ6PT3KgJIAblP9Imh4d3Uvos3MYzggS gOjdO04cN3o/FyeZmMegvidclnNqKIhmkKHSxB8NzCqUxMYPDe8SdY3O/8NynAD0Qh joC9nF0wyGfOn8eDuB3LXwBACcrjRTwSw9l1cLhrzXLjHwydrKTexZYhITLcDvjy1r xv6/0W+SeAB/JHuZWyGDOtQL+NmETf1x9rIlpUSGFamCBUGBG1jo7FY336PLXOoMOo iFVyt8jISCwUQ== Date: Mon, 9 May 2022 14:42:43 +0300 From: Mike Rapoport To: Faiyaz Mohammed Cc: quic_vjitta@quicinc.com, 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42f28e7b-c001-7d01-1eb6-fe963491898e@quicinc.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A53E1140085 X-Stat-Signature: hx7gamfcfyippkic8tabjeqf7z77bn46 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NQ5sYu1M; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspam-User: X-HE-Tag: 1652096562-290912 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 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 and regards, > Mohammed Faiyaz -- Sincerely yours, Mike.