devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org, Alexander Graf <graf@amazon.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@kernel.org>,
	Anthony Yznaga <anthony.yznaga@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Ashish Kalra <ashish.kalra@amd.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Borislav Petkov <bp@alien8.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Ingo Molnar <mingo@redhat.com>, James Gowans <jgowans@amazon.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Pratyush Yadav <ptyadav@amazon.de>,
	Rob Herring <robh+dt@kernel.org>, Rob Herring <robh@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Usama Arif <usama.arif@bytedance.com>,
	Will Deacon <will@kernel.org>,
	devicetree@vger.kernel.org, kexec@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-mm@kvack.org, x86@kernel.org
Subject: Re: [PATCH v4 02/14] memblock: add MEMBLOCK_RSRV_KERN flag
Date: Tue, 18 Feb 2025 15:50:04 +0000	[thread overview]
Message-ID: <20250218155004.n53fcuj2lrl5rxll@master> (raw)
In-Reply-To: <20250206132754.2596694-3-rppt@kernel.org>

On Thu, Feb 06, 2025 at 03:27:42PM +0200, Mike Rapoport wrote:
>From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
>
>to denote areas that were reserved for kernel use either directly with
>memblock_reserve_kern() or via memblock allocations.
>
>Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>---
> include/linux/memblock.h | 16 +++++++++++++++-
> mm/memblock.c            | 32 ++++++++++++++++++++++++--------
> 2 files changed, 39 insertions(+), 9 deletions(-)
>
>diff --git a/include/linux/memblock.h b/include/linux/memblock.h
>index e79eb6ac516f..65e274550f5d 100644
>--- a/include/linux/memblock.h
>+++ b/include/linux/memblock.h
>@@ -50,6 +50,7 @@ enum memblock_flags {
> 	MEMBLOCK_NOMAP		= 0x4,	/* don't add to kernel direct mapping */
> 	MEMBLOCK_DRIVER_MANAGED = 0x8,	/* always detected via a driver */
> 	MEMBLOCK_RSRV_NOINIT	= 0x10,	/* don't initialize struct pages */
>+	MEMBLOCK_RSRV_KERN	= 0x20,	/* memory reserved for kernel use */

Above memblock_flags, there are comments on explaining those flags.

Seems we miss it for MEMBLOCK_RSRV_KERN.

> };
> 
> /**
>@@ -116,7 +117,19 @@ int memblock_add_node(phys_addr_t base, phys_addr_t size, int nid,
> int memblock_add(phys_addr_t base, phys_addr_t size);
> int memblock_remove(phys_addr_t base, phys_addr_t size);
> int memblock_phys_free(phys_addr_t base, phys_addr_t size);
>-int memblock_reserve(phys_addr_t base, phys_addr_t size);
>+int __memblock_reserve(phys_addr_t base, phys_addr_t size, int nid,
>+		       enum memblock_flags flags);
>+
>+static __always_inline int memblock_reserve(phys_addr_t base, phys_addr_t size)
>+{
>+	return __memblock_reserve(base, size, NUMA_NO_NODE, 0);
                                                            ^ MEMBLOCK_NONE ?

>+}
>+
>+static __always_inline int memblock_reserve_kern(phys_addr_t base, phys_addr_t size)
>+{
>+	return __memblock_reserve(base, size, NUMA_NO_NODE, MEMBLOCK_RSRV_KERN);
>+}
>+
> #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
> int memblock_physmem_add(phys_addr_t base, phys_addr_t size);
> #endif
>@@ -477,6 +490,7 @@ static inline __init_memblock bool memblock_bottom_up(void)
> 
> phys_addr_t memblock_phys_mem_size(void);
> phys_addr_t memblock_reserved_size(void);
>+phys_addr_t memblock_reserved_kern_size(int nid);
> unsigned long memblock_estimated_nr_free_pages(void);
> phys_addr_t memblock_start_of_DRAM(void);
> phys_addr_t memblock_end_of_DRAM(void);
>diff --git a/mm/memblock.c b/mm/memblock.c
>index 95af35fd1389..4c33baf4d97c 100644
>--- a/mm/memblock.c
>+++ b/mm/memblock.c
>@@ -491,7 +491,7 @@ static int __init_memblock memblock_double_array(struct memblock_type *type,
> 	 * needn't do it
> 	 */
> 	if (!use_slab)
>-		BUG_ON(memblock_reserve(addr, new_alloc_size));
>+		BUG_ON(memblock_reserve_kern(addr, new_alloc_size));
> 
> 	/* Update slab flag */
> 	*in_slab = use_slab;
>@@ -641,7 +641,7 @@ static int __init_memblock memblock_add_range(struct memblock_type *type,
> #ifdef CONFIG_NUMA
> 			WARN_ON(nid != memblock_get_region_node(rgn));
> #endif
>-			WARN_ON(flags != rgn->flags);
>+			WARN_ON(flags != MEMBLOCK_NONE && flags != rgn->flags);
> 			nr_new++;
> 			if (insert) {
> 				if (start_rgn == -1)
>@@ -901,14 +901,15 @@ int __init_memblock memblock_phys_free(phys_addr_t base, phys_addr_t size)
> 	return memblock_remove_range(&memblock.reserved, base, size);
> }
> 
>-int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
>+int __init_memblock __memblock_reserve(phys_addr_t base, phys_addr_t size,
>+				       int nid, enum memblock_flags flags)
> {
> 	phys_addr_t end = base + size - 1;
> 
>-	memblock_dbg("%s: [%pa-%pa] %pS\n", __func__,
>-		     &base, &end, (void *)_RET_IP_);
>+	memblock_dbg("%s: [%pa-%pa] nid=%d flags=%x %pS\n", __func__,
>+		     &base, &end, nid, flags, (void *)_RET_IP_);
> 
>-	return memblock_add_range(&memblock.reserved, base, size, MAX_NUMNODES, 0);
>+	return memblock_add_range(&memblock.reserved, base, size, nid, flags);
> }
> 
> #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
>@@ -1459,14 +1460,14 @@ phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
> again:
> 	found = memblock_find_in_range_node(size, align, start, end, nid,
> 					    flags);
>-	if (found && !memblock_reserve(found, size))
>+	if (found && !__memblock_reserve(found, size, nid, MEMBLOCK_RSRV_KERN))

Maybe we could use memblock_reserve_kern() directly. If my understanding is
correct, the reserved region's nid is not used.

BTW, one question here. How we handle concurrent memblock allocation? If two
threads find the same available range and do the reservation, it seems to be a
problem to me. Or I missed something?

> 		goto done;
> 
> 	if (numa_valid_node(nid) && !exact_nid) {
> 		found = memblock_find_in_range_node(size, align, start,
> 						    end, NUMA_NO_NODE,
> 						    flags);
>-		if (found && !memblock_reserve(found, size))
>+		if (found && !memblock_reserve_kern(found, size))
> 			goto done;
> 	}
> 
>@@ -1751,6 +1752,20 @@ phys_addr_t __init_memblock memblock_reserved_size(void)
> 	return memblock.reserved.total_size;
> }
> 
>+phys_addr_t __init_memblock memblock_reserved_kern_size(int nid)
>+{
>+	struct memblock_region *r;
>+	phys_addr_t total = 0;
>+
>+	for_each_reserved_mem_region(r) {
>+		if (nid == memblock_get_region_node(r) || !numa_valid_node(nid))
>+			if (r->flags & MEMBLOCK_RSRV_KERN)
>+				total += r->size;
>+	}
>+
>+	return total;
>+}
>+
> /**
>  * memblock_estimated_nr_free_pages - return estimated number of free pages
>  * from memblock point of view
>@@ -2397,6 +2412,7 @@ static const char * const flagname[] = {
> 	[ilog2(MEMBLOCK_NOMAP)] = "NOMAP",
> 	[ilog2(MEMBLOCK_DRIVER_MANAGED)] = "DRV_MNG",
> 	[ilog2(MEMBLOCK_RSRV_NOINIT)] = "RSV_NIT",
>+	[ilog2(MEMBLOCK_RSRV_KERN)] = "RSV_KERN",
> };
> 
> static int memblock_debug_show(struct seq_file *m, void *private)
>-- 
>2.47.2
>

-- 
Wei Yang
Help you, Help me

  reply	other threads:[~2025-02-18 15:50 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06 13:27 [PATCH v4 00/14] kexec: introduce Kexec HandOver (KHO) Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 01/14] mm/mm_init: rename init_reserved_page to init_deferred_page Mike Rapoport
2025-02-18 14:59   ` Wei Yang
2025-02-19  7:13     ` Mike Rapoport
2025-02-20  8:36       ` Wei Yang
2025-02-20 14:54         ` Mike Rapoport
2025-02-25  7:40         ` Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 02/14] memblock: add MEMBLOCK_RSRV_KERN flag Mike Rapoport
2025-02-18 15:50   ` Wei Yang [this message]
2025-02-19  7:24     ` Mike Rapoport
2025-02-23  0:22       ` Wei Yang
2025-03-10  9:51         ` Wei Yang
2025-03-11  5:27           ` Mike Rapoport
2025-03-11 13:41             ` Wei Yang
2025-03-12  5:22               ` Mike Rapoport
2025-02-24  1:31       ` Wei Yang
2025-02-25  7:46         ` Mike Rapoport
2025-02-26  2:09           ` Wei Yang
2025-03-10  7:56             ` Wei Yang
2025-03-10  8:28               ` Mike Rapoport
2025-03-10  9:42                 ` Wei Yang
2025-02-26  1:53   ` Changyuan Lyu
2025-03-13 15:41     ` Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 03/14] memblock: Add support for scratch memory Mike Rapoport
2025-02-24  2:50   ` Wei Yang
2025-02-25  7:47     ` Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 04/14] memblock: introduce memmap_init_kho_scratch() Mike Rapoport
2025-02-24  3:02   ` Wei Yang
2025-02-06 13:27 ` [PATCH v4 05/14] kexec: Add Kexec HandOver (KHO) generation helpers Mike Rapoport
2025-02-10 20:22   ` Jason Gunthorpe
2025-02-10 20:58     ` Pasha Tatashin
2025-02-11 12:49       ` Jason Gunthorpe
2025-02-11 16:14         ` Pasha Tatashin
2025-02-11 16:37           ` Jason Gunthorpe
2025-02-12 15:23             ` Jason Gunthorpe
2025-02-12 16:39               ` Mike Rapoport
2025-02-12 17:43                 ` Jason Gunthorpe
2025-02-23 18:51                   ` Mike Rapoport
2025-02-24 14:28                     ` Jason Gunthorpe
2025-02-12 12:29   ` Thomas Weißschuh
2025-02-06 13:27 ` [PATCH v4 06/14] kexec: Add KHO parsing support Mike Rapoport
2025-02-10 20:50   ` Jason Gunthorpe
2025-03-10 16:20   ` Pratyush Yadav
2025-03-10 17:08     ` Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 07/14] kexec: Add KHO support to kexec file loads Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 08/14] kexec: Add config option for KHO Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 09/14] kexec: Add documentation " Mike Rapoport
2025-02-10 19:26   ` Jason Gunthorpe
2025-02-06 13:27 ` [PATCH v4 10/14] arm64: Add KHO support Mike Rapoport
2025-02-09 10:38   ` Krzysztof Kozlowski
2025-02-06 13:27 ` [PATCH v4 11/14] x86/setup: use memblock_reserve_kern for memory used by kernel Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 12/14] x86: Add KHO support Mike Rapoport
2025-02-24  7:13   ` Wei Yang
2025-02-24 14:36     ` Mike Rapoport
2025-02-25  0:00       ` Wei Yang
2025-02-06 13:27 ` [PATCH v4 13/14] memblock: Add KHO support for reserve_mem Mike Rapoport
2025-02-10 16:03   ` Rob Herring
2025-02-12 16:30     ` Mike Rapoport
2025-02-17  4:04   ` Wei Yang
2025-02-19  7:25     ` Mike Rapoport
2025-02-06 13:27 ` [PATCH v4 14/14] Documentation: KHO: Add memblock bindings Mike Rapoport
2025-02-09 10:29   ` Krzysztof Kozlowski
2025-02-09 15:10     ` Mike Rapoport
2025-02-09 15:23       ` Krzysztof Kozlowski
2025-02-09 20:41         ` Mike Rapoport
2025-02-09 20:49           ` Krzysztof Kozlowski
2025-02-09 20:50             ` Krzysztof Kozlowski
2025-02-10 19:15               ` Jason Gunthorpe
2025-02-10 19:27                 ` Krzysztof Kozlowski
2025-02-10 20:20                   ` Jason Gunthorpe
2025-02-12 16:00                     ` Mike Rapoport
2025-02-07  0:29 ` [PATCH v4 00/14] kexec: introduce Kexec HandOver (KHO) Andrew Morton
2025-02-07  1:28   ` Pasha Tatashin
2025-02-08  1:38     ` Baoquan He
2025-02-08  8:41       ` Mike Rapoport
2025-02-08 11:13         ` Baoquan He
2025-02-09  0:23       ` Pasha Tatashin
2025-02-09  3:07         ` Baoquan He
2025-02-07  8:06   ` Mike Rapoport
2025-02-09 10:33   ` Krzysztof Kozlowski
2025-02-07  4:50 ` Andrew Morton
2025-02-07  8:01   ` Mike Rapoport
2025-02-08 23:39 ` Cong Wang
2025-02-09  0:13   ` Pasha Tatashin
2025-02-09  1:00     ` Cong Wang
2025-02-09  0:51 ` Cong Wang
2025-02-17  3:19 ` RuiRui Yang
2025-02-19  7:32   ` Mike Rapoport
2025-02-19 12:49     ` Dave Young
2025-02-19 13:54       ` Alexander Graf
2025-02-20  1:49         ` Dave Young
2025-02-20 16:43           ` Alexander Gordeev
2025-02-23 17:54             ` Mike Rapoport
2025-02-26 20:08 ` Pratyush Yadav
2025-02-28 20:20   ` Mike Rapoport
2025-02-28 23:04     ` Pratyush Yadav
2025-03-02  9:52       ` Mike Rapoport

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=20250218155004.n53fcuj2lrl5rxll@master \
    --to=richard.weiyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=anthony.yznaga@oracle.com \
    --cc=arnd@arndb.de \
    --cc=ashish.kalra@amd.com \
    --cc=benh@kernel.crashing.org \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=ebiederm@xmission.com \
    --cc=graf@amazon.com \
    --cc=hpa@zytor.com \
    --cc=jgowans@amazon.com \
    --cc=kexec@lists.infradead.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ptyadav@amazon.de \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=saravanak@google.com \
    --cc=skinsburskii@linux.microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=usama.arif@bytedance.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /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).