All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/5] mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory
Date: Fri, 5 Mar 2021 16:35:08 +0100	[thread overview]
Message-ID: <b139d4fe-fdef-b5d9-4fdf-2f79cb00a24a@redhat.com> (raw)
In-Reply-To: <20210304100002.7740-4-osalvador@suse.de>

On 04.03.21 11:00, Oscar Salvador wrote:
> Self stored memmap leads to a sparse memory situation which is unsuitable
> for workloads that requires large contiguous memory chunks, so make this
> an opt-in which needs to be explicitly enabled.
> 
> To control this, let memory_hotplug have its own memory space, as suggested
> by David, so we can add memory_hotplug.memmap_on_memory parameter.
> 
> Signed-off-by: Oscar Salvador <osalvador@suse.de>
> ---
>   Documentation/admin-guide/kernel-parameters.txt | 14 ++++++++++++++
>   mm/Makefile                                     |  5 ++++-
>   mm/memory_hotplug.c                             |  8 +++++++-
>   3 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 04545725f187..e626dab39c60 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2794,6 +2794,20 @@
>   			seconds.  Use this parameter to check at some
>   			other rate.  0 disables periodic checking.
>   
> +	memory_hotplug.memmap_on_memory
> +			[KNL,X86,ARM] Boolean flag to enable this feature.

Right now it can be set on any arch with memory hotplug, right? It's 
simply not effective.

> +			Format: {on | off (default)}
> +			When enabled, memory to build the pages tables for the
> +			memmap array describing the hot-added range will be taken
> +			from the range itself, so the memmap page tables will be
> +			self-hosted.
> +			Since only single memory device ranges are supported at
> +			the moment, this option is disabled by default because
> +			it might have an impact on workloads that needs large
> +			contiguous memory chunks.
> +			The state of the flag can be read in
> +			/sys/module/memory_hotplug/parameters/memmap_on_memory.

Maybe want to add that even if enabled, there are cases where it is not 
effective?

> +
>   	memtest=	[KNL,X86,ARM,PPC] Enable memtest
>   			Format: <integer>
>   			default : 0 <disable>
> diff --git a/mm/Makefile b/mm/Makefile
> index 72227b24a616..82ae9482f5e3 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -58,9 +58,13 @@ obj-y			:= filemap.o mempool.o oom_kill.o fadvise.o \
>   page-alloc-y := page_alloc.o
>   page-alloc-$(CONFIG_SHUFFLE_PAGE_ALLOCATOR) += shuffle.o
>   
> +# Give 'memory_hotplug' its own module-parameter namespace
> +memory-hotplug-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
> +
>   obj-y += page-alloc.o
>   obj-y += init-mm.o
>   obj-y += memblock.o
> +obj-y += $(memory-hotplug-y)
>   
>   ifdef CONFIG_MMU
>   	obj-$(CONFIG_ADVISE_SYSCALLS)	+= madvise.o
> @@ -83,7 +87,6 @@ obj-$(CONFIG_SLUB) += slub.o
>   obj-$(CONFIG_KASAN)	+= kasan/
>   obj-$(CONFIG_KFENCE) += kfence/
>   obj-$(CONFIG_FAILSLAB) += failslab.o
> -obj-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
>   obj-$(CONFIG_MEMTEST)		+= memtest.o
>   obj-$(CONFIG_MIGRATION) += migrate.o
>   obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o khugepaged.o
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 63e5a0e9a6f3..94b0ec3d2ff2 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -42,7 +42,13 @@
>   #include "internal.h"
>   #include "shuffle.h"
>   
> -static bool memmap_on_memory;
> +
> +/*
> + * memory_hotplug.memmap_on_memory parameter
> + */
> +static bool memmap_on_memory __ro_after_init;
> +module_param(memmap_on_memory, bool, 0444);
> +MODULE_PARM_DESC(memmap_on_memory, "Enable memmap on memory for memory hotplug");
>   

Wondering if this makes sense getting wrapped in

#ifdef CONFIG MHP_MEMMAP_ON_MEMORY

just a thought.

LGTM

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2021-03-05 15:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-04  9:59 [PATCH v3 0/5] Allocate memmap from hotadded memory (per device) Oscar Salvador
2021-03-04  9:59 ` [PATCH v3 1/5] mm,memory_hotplug: Allocate memmap from the added memory range Oscar Salvador
2021-03-08  3:16   ` Zi Yan
2021-03-08 14:04     ` Oscar Salvador
2021-03-08 14:06       ` David Hildenbrand
2021-03-04  9:59 ` [PATCH v3 2/5] acpi,memhotplug: Enable MHP_MEMMAP_ON_MEMORY when supported Oscar Salvador
2021-03-04 10:00 ` [PATCH v3 3/5] mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory Oscar Salvador
2021-03-05 15:35   ` David Hildenbrand [this message]
2021-03-08 15:46     ` Oscar Salvador
2021-03-04 10:00 ` [PATCH v3 4/5] x86/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE Oscar Salvador
2021-03-05 15:32   ` David Hildenbrand
2021-03-07 22:14     ` Oscar Salvador
2021-03-04 10:00 ` [PATCH v3 5/5] arm64/Kconfig: " Oscar Salvador
2021-03-05 15:32   ` 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=b139d4fe-fdef-b5d9-4fdf-2f79cb00a24a@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@soleen.com \
    --cc=vbabka@suse.cz \
    /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.