Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Faiyaz Mohammed <quic_faiyazm@quicinc.com>
Subject: Re: [PATCH] mm: memblock: avoid to create memmap for memblock nomap
 regions
To:     Mike Rapoport <rppt@kernel.org>
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>
References: <1649704172-13181-1-git-send-email-quic_faiyazm@quicinc.com>
 <YlW2TO0O8qDHpkGW@kernel.org>
Message-ID: <7b18bea8-b996-601d-f490-cb8aadfffa1b@quicinc.com>
Date:   Thu, 5 May 2022 20:46:15 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <YlW2TO0O8qDHpkGW@kernel.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


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

--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1180,8 +1180,10 @@ int __init __weak
early_init_dt_reserve_memory_arch(phys_addr_t base,
                 */
                if (memblock_is_region_reserved(base, size))
                        return -EBUSY;
-
-               return memblock_mark_nomap(base, size);
+               if (remove_nomap_region)
+                       return memblock_remove(base, size);
+               else
+                       return memblock_mark_nomap(base, size);
Thanks and regards,
Mohammed Faiyaz