[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zh9l_LpThq9aFUR7@kernel.org>
Date: Wed, 17 Apr 2024 09:02:36 +0300
From: Mike Rapoport <rppt@...nel.org>
To: skseofh@...il.com
Cc: robh@...nel.org, saravanak@...gle.com, akpm@...ux-foundation.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Daero Lee <daero_le.lee@...sung.com>
Subject: Re: [PATCH v2] memblock: add no-map alloc functions
On Tue, Apr 16, 2024 at 09:06:35PM +0900, skseofh@...il.com wrote:
> From: Daero Lee <daero_le.lee@...sung.com>
>
> Like reserved-memory with the 'no-map' property and only 'size' property
> (w/o 'reg' property), there are memory regions need to be allocated in
> memblock.memory marked with the MEMBLOCK_NOMAP flag, but should not be
> allocated in memblock.reserved.
This still does not explain why you need such regions.
As Wei Yang explained, memblock does not allocate memory from
memblock.reserved. The memblock.reserved array represents memory that is in
use by firmware or by early kernel allocations and cannot be freed to page
allocator.
If you have a region that's _NOMAP in memblock.memory and is absent in
memblock.reserved it will not be mapped by the kernel page tables, but it
will be considered as free memory by the core mm.
Is this really what you want?
> example : arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> bman_fbpr: bman-fbpr {
> compatible = "shared-dma-pool";
> size = <0 0x1000000>;
> alignment = <0 0x1000000>;
> no-map;
> };
>
> qman_fqd: qman-fqd {
> compatible = "shared-dma-pool";
> size = <0 0x400000>;
> alignment = <0 0x400000>;
> no-map;
> };
>
> qman_pfdr: qman-pfdr {
> compatible = "shared-dma-pool";
> size = <0 0x2000000>;
> alignment = <0 0x2000000>;
> no-map;
> };
> };
>
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists