From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Oscar Salvador <osalvador@suse.de>,
Jianyong Wu <Jianyong.Wu@arm.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Vineet Gupta <vgupta@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Huacai Chen <chenhuacai@kernel.org>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Eric Biederman <ebiederm@xmission.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-s390@vger.kernel.org, linux-mm@kvack.org,
kexec@lists.infradead.org
Subject: Re: [PATCH v2 2/5] memblock: improve MEMBLOCK_HOTPLUG documentation
Date: Tue, 5 Oct 2021 17:35:57 -0700 [thread overview]
Message-ID: <YVzvbUr2zO/Nw0Xf@kernel.org> (raw)
In-Reply-To: <20211004093605.5830-3-david@redhat.com>
On Mon, Oct 04, 2021 at 11:36:02AM +0200, David Hildenbrand wrote:
> The description of MEMBLOCK_HOTPLUG is currently short and consequently
> misleading: we're actually dealing with a memory region that might get
> hotunplugged later (i.e., the platform+firmware supports it), yet it is
> indicated in the firmware-provided memory map as system ram that will just
> get used by the system for any purpose when not taking special care. The
> firmware marked this memory region as a hot(un)plugged (e.g., hotplugged
> before reboot), implying that it might get hotunplugged again later.
>
> Whether we consider this information depends on the "movable_node" kernel
> commandline parameter: only with "movable_node" set, we'll try keeping
> this memory hotunpluggable, for example, by not serving early allocations
> from this memory region and by letting the buddy manage it using the
> ZONE_MOVABLE.
>
> Let's make this clearer by extending the documentation.
>
> Note: kexec *has to* indicate this memory to the second kernel. With
> "movable_node" set, we don't want to place kexec-images on this memory.
> Without "movable_node" set, we don't care and can place kexec-images on
> this memory. In both cases, after successful memory hotunplug, kexec has to
> be re-armed to update the memory map for the second kernel and to place the
> kexec-images somewhere else.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> include/linux/memblock.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 34de69b3b8ba..4ee8dd2d63a7 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -28,7 +28,11 @@ extern unsigned long long max_possible_pfn;
> /**
> * enum memblock_flags - definition of memory region attributes
> * @MEMBLOCK_NONE: no special request
> - * @MEMBLOCK_HOTPLUG: hotpluggable region
> + * @MEMBLOCK_HOTPLUG: memory region indicated in the firmware-provided memory
> + * map during early boot as hot(un)pluggable system RAM (e.g., memory range
> + * that might get hotunplugged later). With "movable_node" set on the kernel
> + * commandline, try keeping this memory region hotunpluggable. Does not apply
> + * to memblocks added ("hotplugged") after early boot.
> * @MEMBLOCK_MIRROR: mirrored region
> * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
> * reserved in the memory map; refer to memblock_mark_nomap() description
> --
> 2.31.1
>
--
Sincerely yours,
Mike.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Oscar Salvador <osalvador@suse.de>,
Jianyong Wu <Jianyong.Wu@arm.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Vineet Gupta <vgupta@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Huacai Chen <chenhuacai@kernel.org>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Eric Biederman <ebiederm@xmission.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-s390@vger.kernel.org, linux-mm@kvack.org,
kexec@lists.infradead.org
Subject: Re: [PATCH v2 2/5] memblock: improve MEMBLOCK_HOTPLUG documentation
Date: Wed, 06 Oct 2021 00:35:57 +0000 [thread overview]
Message-ID: <YVzvbUr2zO/Nw0Xf@kernel.org> (raw)
In-Reply-To: <20211004093605.5830-3-david@redhat.com>
On Mon, Oct 04, 2021 at 11:36:02AM +0200, David Hildenbrand wrote:
> The description of MEMBLOCK_HOTPLUG is currently short and consequently
> misleading: we're actually dealing with a memory region that might get
> hotunplugged later (i.e., the platform+firmware supports it), yet it is
> indicated in the firmware-provided memory map as system ram that will just
> get used by the system for any purpose when not taking special care. The
> firmware marked this memory region as a hot(un)plugged (e.g., hotplugged
> before reboot), implying that it might get hotunplugged again later.
>
> Whether we consider this information depends on the "movable_node" kernel
> commandline parameter: only with "movable_node" set, we'll try keeping
> this memory hotunpluggable, for example, by not serving early allocations
> from this memory region and by letting the buddy manage it using the
> ZONE_MOVABLE.
>
> Let's make this clearer by extending the documentation.
>
> Note: kexec *has to* indicate this memory to the second kernel. With
> "movable_node" set, we don't want to place kexec-images on this memory.
> Without "movable_node" set, we don't care and can place kexec-images on
> this memory. In both cases, after successful memory hotunplug, kexec has to
> be re-armed to update the memory map for the second kernel and to place the
> kexec-images somewhere else.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> include/linux/memblock.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 34de69b3b8ba..4ee8dd2d63a7 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -28,7 +28,11 @@ extern unsigned long long max_possible_pfn;
> /**
> * enum memblock_flags - definition of memory region attributes
> * @MEMBLOCK_NONE: no special request
> - * @MEMBLOCK_HOTPLUG: hotpluggable region
> + * @MEMBLOCK_HOTPLUG: memory region indicated in the firmware-provided memory
> + * map during early boot as hot(un)pluggable system RAM (e.g., memory range
> + * that might get hotunplugged later). With "movable_node" set on the kernel
> + * commandline, try keeping this memory region hotunpluggable. Does not apply
> + * to memblocks added ("hotplugged") after early boot.
> * @MEMBLOCK_MIRROR: mirrored region
> * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
> * reserved in the memory map; refer to memblock_mark_nomap() description
> --
> 2.31.1
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Oscar Salvador <osalvador@suse.de>,
Jianyong Wu <Jianyong.Wu@arm.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Vineet Gupta <vgupta@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Huacai Chen <chenhuacai@kernel.org>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Eric Biederman <ebiederm@xmission.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-s390@vger.kernel.org, linux-mm@kvack.org,
kexec@lists.infradead.org
Subject: Re: [PATCH v2 2/5] memblock: improve MEMBLOCK_HOTPLUG documentation
Date: Tue, 5 Oct 2021 17:35:57 -0700 [thread overview]
Message-ID: <YVzvbUr2zO/Nw0Xf@kernel.org> (raw)
In-Reply-To: <20211004093605.5830-3-david@redhat.com>
On Mon, Oct 04, 2021 at 11:36:02AM +0200, David Hildenbrand wrote:
> The description of MEMBLOCK_HOTPLUG is currently short and consequently
> misleading: we're actually dealing with a memory region that might get
> hotunplugged later (i.e., the platform+firmware supports it), yet it is
> indicated in the firmware-provided memory map as system ram that will just
> get used by the system for any purpose when not taking special care. The
> firmware marked this memory region as a hot(un)plugged (e.g., hotplugged
> before reboot), implying that it might get hotunplugged again later.
>
> Whether we consider this information depends on the "movable_node" kernel
> commandline parameter: only with "movable_node" set, we'll try keeping
> this memory hotunpluggable, for example, by not serving early allocations
> from this memory region and by letting the buddy manage it using the
> ZONE_MOVABLE.
>
> Let's make this clearer by extending the documentation.
>
> Note: kexec *has to* indicate this memory to the second kernel. With
> "movable_node" set, we don't want to place kexec-images on this memory.
> Without "movable_node" set, we don't care and can place kexec-images on
> this memory. In both cases, after successful memory hotunplug, kexec has to
> be re-armed to update the memory map for the second kernel and to place the
> kexec-images somewhere else.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> include/linux/memblock.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 34de69b3b8ba..4ee8dd2d63a7 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -28,7 +28,11 @@ extern unsigned long long max_possible_pfn;
> /**
> * enum memblock_flags - definition of memory region attributes
> * @MEMBLOCK_NONE: no special request
> - * @MEMBLOCK_HOTPLUG: hotpluggable region
> + * @MEMBLOCK_HOTPLUG: memory region indicated in the firmware-provided memory
> + * map during early boot as hot(un)pluggable system RAM (e.g., memory range
> + * that might get hotunplugged later). With "movable_node" set on the kernel
> + * commandline, try keeping this memory region hotunpluggable. Does not apply
> + * to memblocks added ("hotplugged") after early boot.
> * @MEMBLOCK_MIRROR: mirrored region
> * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
> * reserved in the memory map; refer to memblock_mark_nomap() description
> --
> 2.31.1
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Oscar Salvador <osalvador@suse.de>,
Jianyong Wu <Jianyong.Wu@arm.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Vineet Gupta <vgupta@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Huacai Chen <chenhuacai@kernel.org>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Eric Biederman <ebiederm@xmission.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-s390@vger.kernel.org, linux-mm@kvack.org,
kexec@lists.infradead.org
Subject: Re: [PATCH v2 2/5] memblock: improve MEMBLOCK_HOTPLUG documentation
Date: Tue, 5 Oct 2021 17:35:57 -0700 [thread overview]
Message-ID: <YVzvbUr2zO/Nw0Xf@kernel.org> (raw)
In-Reply-To: <20211004093605.5830-3-david@redhat.com>
On Mon, Oct 04, 2021 at 11:36:02AM +0200, David Hildenbrand wrote:
> The description of MEMBLOCK_HOTPLUG is currently short and consequently
> misleading: we're actually dealing with a memory region that might get
> hotunplugged later (i.e., the platform+firmware supports it), yet it is
> indicated in the firmware-provided memory map as system ram that will just
> get used by the system for any purpose when not taking special care. The
> firmware marked this memory region as a hot(un)plugged (e.g., hotplugged
> before reboot), implying that it might get hotunplugged again later.
>
> Whether we consider this information depends on the "movable_node" kernel
> commandline parameter: only with "movable_node" set, we'll try keeping
> this memory hotunpluggable, for example, by not serving early allocations
> from this memory region and by letting the buddy manage it using the
> ZONE_MOVABLE.
>
> Let's make this clearer by extending the documentation.
>
> Note: kexec *has to* indicate this memory to the second kernel. With
> "movable_node" set, we don't want to place kexec-images on this memory.
> Without "movable_node" set, we don't care and can place kexec-images on
> this memory. In both cases, after successful memory hotunplug, kexec has to
> be re-armed to update the memory map for the second kernel and to place the
> kexec-images somewhere else.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> include/linux/memblock.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 34de69b3b8ba..4ee8dd2d63a7 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -28,7 +28,11 @@ extern unsigned long long max_possible_pfn;
> /**
> * enum memblock_flags - definition of memory region attributes
> * @MEMBLOCK_NONE: no special request
> - * @MEMBLOCK_HOTPLUG: hotpluggable region
> + * @MEMBLOCK_HOTPLUG: memory region indicated in the firmware-provided memory
> + * map during early boot as hot(un)pluggable system RAM (e.g., memory range
> + * that might get hotunplugged later). With "movable_node" set on the kernel
> + * commandline, try keeping this memory region hotunpluggable. Does not apply
> + * to memblocks added ("hotplugged") after early boot.
> * @MEMBLOCK_MIRROR: mirrored region
> * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
> * reserved in the memory map; refer to memblock_mark_nomap() description
> --
> 2.31.1
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
next prev parent reply other threads:[~2021-10-06 0:35 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 9:36 [PATCH v2 0/5] mm/memory_hotplug: full support for add_memory_driver_managed() with CONFIG_ARCH_KEEP_MEMBLOCK David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` [PATCH v2 0/5] mm/memory_hotplug: full support for add_memory_driver_managed() with CONFIG_ARCH_KEEP David Hildenbrand
2021-10-04 9:36 ` [PATCH v2 1/5] mm/memory_hotplug: handle memblock_add_node() failures in add_memory_resource() David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` [PATCH v2 2/5] memblock: improve MEMBLOCK_HOTPLUG documentation David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-06 0:35 ` Mike Rapoport [this message]
2021-10-06 0:35 ` Mike Rapoport
2021-10-06 0:35 ` Mike Rapoport
2021-10-06 0:35 ` Mike Rapoport
2021-10-04 9:36 ` [PATCH v2 3/5] memblock: allow to specify flags with memblock_add_node() David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 19:31 ` Shahab Vahedi
2021-10-04 19:31 ` Shahab Vahedi
2021-10-04 19:31 ` Shahab Vahedi
2021-10-04 19:31 ` Shahab Vahedi
2021-10-06 0:36 ` Mike Rapoport
2021-10-06 0:36 ` Mike Rapoport
2021-10-06 0:36 ` Mike Rapoport
2021-10-06 0:36 ` Mike Rapoport
2021-10-04 9:36 ` [PATCH v2 4/5] memblock: add MEMBLOCK_DRIVER_MANAGED to mimic IORESOURCE_SYSRAM_DRIVER_MANAGED David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-06 0:35 ` Mike Rapoport
2021-10-06 0:35 ` Mike Rapoport
2021-10-06 0:35 ` Mike Rapoport
2021-10-06 0:35 ` Mike Rapoport
2021-10-04 9:36 ` [PATCH v2 5/5] mm/memory_hotplug: indicate MEMBLOCK_DRIVER_MANAGED with IORESOURCE_SYSRAM_DRIVER_MANAGED David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` David Hildenbrand
2021-10-04 9:36 ` [PATCH v2 5/5] mm/memory_hotplug: indicate MEMBLOCK_DRIVER_MANAGED with IORESOURCE_SYSRAM_DRIVER_MAN David Hildenbrand
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=YVzvbUr2zO/Nw0Xf@kernel.org \
--to=rppt@kernel.org \
--cc=Jianyong.Wu@arm.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=arnd@arndb.de \
--cc=borntraeger@de.ibm.com \
--cc=chenhuacai@kernel.org \
--cc=david@redhat.com \
--cc=ebiederm@xmission.com \
--cc=geert@linux-m68k.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jiaxun.yang@flygoat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=tsbogend@alpha.franken.de \
--cc=vgupta@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.