From: Wei Yang <richard.weiyang@gmail.com>
To: skseofh@gmail.com
Cc: robh@kernel.org, saravanak@google.com, rppt@kernel.org,
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 02:23:57 +0000 [thread overview]
Message-ID: <20240417022357.glrgkb5cg6ajxnqd@master> (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.
We don't "allocate" memory from memblock.memory directly.
We present memory in memblock.memory and "allocate" a memory by marking it in
memblock.reserved.
>
>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;
> };
> };
>
>So, functions were added that find the required memory area in
>memblock.memory, but do not allocate it to memblock.reserved.
>
>In previous patch(a7259df), early_init_dt_alloc_reserved_memory was
You want to say this patch introduced a regression?
>modified to use memblock_phys_alloc_range allocating memory in
>memblock.reserved, instead of memblock_find_in_range that just find the
>available region. But if there is a 'no-map' property, memory region
>should not be allocated to memblock.reserved.
If my understanding is correct, memblock_phys_free() is called if 'no-map'
property is set. This would release the "allocation" in memblock.reserved.
>
>So, the early_init_dt_alloc_reserved_memory_arch function was modified
>using the no-map alloc function.
>
>Signed-off-by: Daero Lee <daero_le.lee@samsung.com>
>---
> drivers/of/of_reserved_mem.c | 9 +++--
> mm/memblock.c | 78 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 84 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>index 8236ecae2953..504f2f60689c 100644
>--- a/drivers/of/of_reserved_mem.c
>+++ b/drivers/of/of_reserved_mem.c
>@@ -40,15 +40,18 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
>
> end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
> align = !align ? SMP_CACHE_BYTES : align;
>- base = memblock_phys_alloc_range(size, align, start, end);
>+ if (nomap) {
>+ base = memblock_phys_alloc_range_nomap(size, align, start, end);
>+ } else {
>+ base = memblock_phys_alloc_range(size, align, start, end);
>+ }
>+
> if (!base)
> return -ENOMEM;
>
> *res_base = base;
> if (nomap) {
> err = memblock_mark_nomap(base, size);
>- if (err)
>- memblock_phys_free(base, size);
I see you removed it here, seems does the same as before.
> }
>
> kmemleak_ignore_phys(base);
>diff --git a/mm/memblock.c b/mm/memblock.c
>index d09136e040d3..f103f1ecbfad 100644
>--- a/mm/memblock.c
>+++ b/mm/memblock.c
>@@ -1506,6 +1506,72 @@ phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
> return found;
> }
>
>+phys_addr_t __init memblock_alloc_range_nid_nomap(phys_addr_t size,
>+ phys_addr_t align, phys_addr_t start,
>+ phys_addr_t end, int nid,
>+ bool exact_nid)
>+{
>+ enum memblock_flags flags = choose_memblock_flags();
>+ phys_addr_t found;
>+
>+ if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
>+ nid = NUMA_NO_NODE;
>+
>+ if (!align) {
>+ /* Can't use WARNs this early in boot on powerpc */
>+ dump_stack();
>+ align = SMP_CACHE_BYTES;
>+ }
>+
>+again:
>+ found = memblock_find_in_range_node(size, align, start, end, nid,
>+ flags);
>+ if (found)
>+ goto done;
>+
>+ if (nid != NUMA_NO_NODE && !exact_nid) {
>+ found = memblock_find_in_range_node(size, align, start,
>+ end, NUMA_NO_NODE,
>+ flags);
>+ if (found)
>+ goto done;
>+ }
>+
>+ if (flags & MEMBLOCK_MIRROR) {
>+ flags &= ~MEMBLOCK_MIRROR;
>+ pr_warn_ratelimited("Could not allocate %pap bytes of mirrored memory\n",
>+ &size);
>+ goto again;
>+ }
>+
>+ return 0;
>+
>+done:
>+ /*
>+ * Skip kmemleak for those places like kasan_init() and
>+ * early_pgtable_alloc() due to high volume.
>+ */
>+ if (end != MEMBLOCK_ALLOC_NOLEAKTRACE)
>+ /*
>+ * Memblock allocated blocks are never reported as
>+ * leaks. This is because many of these blocks are
>+ * only referred via the physical address which is
>+ * not looked up by kmemleak.
>+ */
>+ kmemleak_alloc_phys(found, size, 0);
>+
>+ /*
>+ * Some Virtual Machine platforms, such as Intel TDX or AMD SEV-SNP,
>+ * require memory to be accepted before it can be used by the
>+ * guest.
>+ *
>+ * Accept the memory of the allocated buffer.
>+ */
>+ accept_memory(found, found + size);
>+
>+ return found;
>+}
>+
> /**
> * memblock_phys_alloc_range - allocate a memory block inside specified range
> * @size: size of memory block to be allocated in bytes
>@@ -1530,6 +1596,18 @@ phys_addr_t __init memblock_phys_alloc_range(phys_addr_t size,
> false);
> }
>
>+phys_addr_t __init memblock_phys_alloc_range_nomap(phys_addr_t size,
>+ phys_addr_t align,
>+ phys_addr_t start,
>+ phys_addr_t end)
>+{
>+ memblock_dbg("%s: %llu bytes align=0x%llx from=%pa max_addr=%pa %pS\n",
>+ __func__, (u64)size, (u64)align, &start, &end,
>+ (void *)_RET_IP_);
>+ return memblock_alloc_range_nid_nomap(size, align, start, end,
>+ NUMA_NO_NODE, false);
>+}
>+
> /**
> * memblock_phys_alloc_try_nid - allocate a memory block from specified NUMA node
> * @size: size of memory block to be allocated in bytes
>--
>2.25.1
>
--
Wei Yang
Help you, Help me
next prev parent reply other threads:[~2024-04-17 2:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 12:06 skseofh
2024-04-16 12:06 ` skseofh
2024-04-17 2:23 ` Wei Yang [this message]
2024-04-17 6:02 ` Mike Rapoport
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=20240417022357.glrgkb5cg6ajxnqd@master \
--to=richard.weiyang@gmail.com \
--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=rppt@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