linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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