Received-SPF: pass (google.com: domain of linux-kernel+bounces-82999-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 27 Feb 2024 12:00:40 +0200
From: Mike Rapoport <rppt@kernel.org>
To: "Aiqun Yu (Maria)" <quic_aiquny@quicinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Vijayanand Jitta <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: <Zd2yyOuZNAUZgdac@kernel.org>
References: <YnQBKPWtPa87y4NA@kernel.org>
 <42f28e7b-c001-7d01-1eb6-fe963491898e@quicinc.com>
 <Ynj+M9cRm6zdCMMi@kernel.org>
 <22aca197-8d18-2c9e-b3c4-f6fdc893ceb1@quicinc.com>
 <Yu1t8TpXT1f372v/@kernel.org>
 <76cb3b37-5887-404f-95b7-10a22a7ba65b@quicinc.com>
 <ZcxvKvSfJv6L2O9e@kernel.org>
 <CAA8EJpqpGN6yzd5pUs06aax=L5wDwPK6aM6R2X784y7ot+P-aQ@mail.gmail.com>
 <ZcyEzHva7pq-3Zav@kernel.org>
 <a44a435c-e52d-4ee5-b05e-9f43a071c479@quicinc.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a44a435c-e52d-4ee5-b05e-9f43a071c479@quicinc.com>

On Tue, Feb 20, 2024 at 02:28:32PM +0800, Aiqun Yu (Maria) wrote:
> > > > > 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?
> > > 
> > > That was the question. It looks like your opinion on /memory was that
> > > it describes "memory available to Linux", while device tree spec
> > > defines it as "physical memory layout".
> > >
> > I suggested a workaround that will allow to save memory map for the
> > carveout.
> > The memory map is a run time description of the physical memory layout and
> > core mm relies on availability of struct page for every physical frame.
> > Having only partial memory map will lead to subtle bugs and crashes, so
> > it's not an option.
>
> Any idea of a formal solution for this case?
> It is a real use case for the commercial device. Memory saving is always a
> good topic for commercial devices. So for a total 128MB memory, ~60MB for
> kernel total available memory, and ~1M free memory saving is important from
> OEM point of view.
> 
> There are 3 types of memory:
> 1. used by firmware and not available to kernel at any time.
> Either struct page can be avoided by kernel. Or bootloader not pass this
> part of physical memory was discussed here.
> Any good ideas?

As I said, struct page must exist for all physical memory known to kernel.
If hiding the memory that is not available to kernel does not work for you
I don't have other ideas.

> 2. shared by firmware/subsystem, and can be read/write access by kernel.
> Just as it is now. Struct page can be allocated inside kernel and also
> reserved memory for this.
> 3. freely used by kernel.
> Just as it is now.


-- 
Sincerely yours,
Mike.