Re: [PATCH] mm: memblock: avoid to create memmap for memblock nomap regions

[Mike Rapoport <rppt@kernel.org>]

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.