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 226CBC433F5 for ; Tue, 12 Apr 2022 17:26:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91B8E6B0072; Tue, 12 Apr 2022 13:26:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A1F16B0073; Tue, 12 Apr 2022 13:26:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71B176B0074; Tue, 12 Apr 2022 13:26:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 5F6276B0072 for ; Tue, 12 Apr 2022 13:26:49 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 26C1C221E1 for ; Tue, 12 Apr 2022 17:26:49 +0000 (UTC) X-FDA: 79348906938.14.55CD974 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf07.hostedemail.com (Postfix) with ESMTP id 7CD7640009 for ; Tue, 12 Apr 2022 17:26:48 +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 ams.source.kernel.org (Postfix) with ESMTPS id 62296B81F58; Tue, 12 Apr 2022 17:26:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69718C385A1; Tue, 12 Apr 2022 17:26:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649784405; bh=5fBiB9n+naRmExVYTrfBR6Y0GO2FDmg4/T8dW79QLCA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uybX+7vqcUMrlKabYMrKLxwaPbspd2HZmFKgjmSgNwUo5KRUgiqpc/0eVigepUKEL pxGEKibtkMnxIcTFszfqT2CP7qzlIc+eA+lkZPZ45D+dNd+M54X2IqpnmMIJRMRF4B 7iXxsupYtPcHTnOvS324q9mMJjHUP2XTeVI4T7DfsBIZAzzqPvrrslpTU8Oq/LX/rn LplL6FUmJiem1Y/kuTLA/X3MH7KkFUK/26cC0K5CgkDO7L8EeXmzk+7DSovcenZfKF P5XzAX5TwfYYMpjHnOqDAE5KqKzuZGsU/fgBEYUADuxNFaoawqZUjRaS2awQvI0nNy GQV+Uk8lVNMJg== Date: Tue, 12 Apr 2022 20:26:36 +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 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1649704172-13181-1-git-send-email-quic_faiyazm@quicinc.com> Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uybX+7vq; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: 1ihjufcpteex6cib3r71rup5c3y59jak X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7CD7640009 X-HE-Tag: 1649784408-262713 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, 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. -- Sincerely yours, Mike.