From: Mike Rapoport <rppt@kernel.org>
To: skseofh@gmail.com
Cc: robh@kernel.org, saravanak@google.com, akpm@linux-foundation.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Daero Lee <daero_le.lee@samsung.com>
Subject: Re: [PATCH v2] memblock: add no-map alloc functions
Date: Wed, 17 Apr 2024 09:02:36 +0300 [thread overview]
Message-ID: <Zh9l_LpThq9aFUR7@kernel.org> (raw)
In-Reply-To: <20240416120635.361838-2-skseofh@gmail.com>
On Tue, Apr 16, 2024 at 09:06:35PM +0900, skseofh@gmail.com wrote:
> From: Daero Lee <daero_le.lee@samsung.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.
next prev parent reply other threads:[~2024-04-17 6:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 12:06 [PATCH v2] memblock: add no-map alloc functions skseofh
2024-04-16 12:06 ` skseofh
2024-04-17 2:23 ` Wei Yang
2024-04-17 6:02 ` Mike Rapoport [this message]
2024-04-18 14:54 ` DaeRo Lee
2024-04-18 18:03 ` Mike Rapoport
2024-04-19 1:46 ` DaeRo Lee
2024-04-19 1:59 ` DaeRo Lee
2024-04-27 2:42 ` DaeRo Lee
2024-04-27 3:27 ` DaeRo Lee
2024-04-27 8:49 ` Mike Rapoport
2024-04-27 10:24 ` DaeRo Lee
2024-04-28 6:33 ` Mike Rapoport
2024-04-28 10:36 ` DaeRo Lee
2024-04-28 12:00 ` Mike Rapoport
2024-04-28 12:52 ` DaeRo Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zh9l_LpThq9aFUR7@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=daero_le.lee@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=skseofh@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).