From: David Hildenbrand <david@redhat.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
linux-mm@kvack.org, akpm@linux-foundation.org,
mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
npiggin@gmail.com, christophe.leroy@csgroup.eu
Cc: Vishal Verma <vishal.l.verma@intel.com>,
Michal Hocko <mhocko@suse.com>,
Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH v2 3/5] mm/hotplug: Simplify the handling of MHP_MEMMAP_ON_MEMORY flag
Date: Thu, 6 Jul 2023 11:24:39 +0200 [thread overview]
Message-ID: <0efcd10b-dff8-d011-e192-5feaedc2ee2d@redhat.com> (raw)
In-Reply-To: <20230706085041.826340-4-aneesh.kumar@linux.ibm.com>
On 06.07.23 10:50, Aneesh Kumar K.V wrote:
> Instead of checking for memmap on memory feature enablement within the
> functions checking for alignment, use the kernel parameter to control the
> memory hotplug flags. The generic kernel now enables memmap on memory
> feature if the hotplug flag request for the same.
>
> The ACPI code now can pass the flag unconditionally because the kernel will
> fallback to not using the feature if the alignment rules are not met.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 3 +--
> include/linux/memory_hotplug.h | 14 ++++++++++++++
> mm/memory_hotplug.c | 35 +++++++++++-----------------------
> 3 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 24f662d8bd39..4d0096fc4cc2 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -211,8 +211,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
> if (!info->length)
> continue;
>
> - if (mhp_supports_memmap_on_memory(info->length))
> - mhp_flags |= MHP_MEMMAP_ON_MEMORY;
> + mhp_flags |= get_memmap_on_memory_flags();
> result = __add_memory(mgid, info->start_addr, info->length,
> mhp_flags);
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index a769f44b8368..af7017122506 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -358,4 +358,18 @@ bool mhp_supports_memmap_on_memory(unsigned long size);
> bool __mhp_supports_memmap_on_memory(unsigned long size);
> #endif /* CONFIG_MEMORY_HOTPLUG */
>
> +#ifdef CONFIG_MHP_MEMMAP_ON_MEMORY
> +extern bool memmap_on_memory;
> +static inline unsigned long get_memmap_on_memory_flags(void)
> +{
> + if (memmap_on_memory)
> + return MHP_MEMMAP_ON_MEMORY;
> + return 0;
> +}
> +#else
> +static inline unsigned long get_memmap_on_memory_flags(void)
> +{
> + return 0;
> +}
> +#endif
That's kind-of ugly TBH.
Why do we need this change?
--
Cheers,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
linux-mm@kvack.org, akpm@linux-foundation.org,
mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
npiggin@gmail.com, christophe.leroy@csgroup.eu
Cc: Oscar Salvador <osalvador@suse.de>,
Michal Hocko <mhocko@suse.com>,
Vishal Verma <vishal.l.verma@intel.com>
Subject: Re: [PATCH v2 3/5] mm/hotplug: Simplify the handling of MHP_MEMMAP_ON_MEMORY flag
Date: Thu, 6 Jul 2023 11:24:39 +0200 [thread overview]
Message-ID: <0efcd10b-dff8-d011-e192-5feaedc2ee2d@redhat.com> (raw)
In-Reply-To: <20230706085041.826340-4-aneesh.kumar@linux.ibm.com>
On 06.07.23 10:50, Aneesh Kumar K.V wrote:
> Instead of checking for memmap on memory feature enablement within the
> functions checking for alignment, use the kernel parameter to control the
> memory hotplug flags. The generic kernel now enables memmap on memory
> feature if the hotplug flag request for the same.
>
> The ACPI code now can pass the flag unconditionally because the kernel will
> fallback to not using the feature if the alignment rules are not met.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 3 +--
> include/linux/memory_hotplug.h | 14 ++++++++++++++
> mm/memory_hotplug.c | 35 +++++++++++-----------------------
> 3 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 24f662d8bd39..4d0096fc4cc2 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -211,8 +211,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
> if (!info->length)
> continue;
>
> - if (mhp_supports_memmap_on_memory(info->length))
> - mhp_flags |= MHP_MEMMAP_ON_MEMORY;
> + mhp_flags |= get_memmap_on_memory_flags();
> result = __add_memory(mgid, info->start_addr, info->length,
> mhp_flags);
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index a769f44b8368..af7017122506 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -358,4 +358,18 @@ bool mhp_supports_memmap_on_memory(unsigned long size);
> bool __mhp_supports_memmap_on_memory(unsigned long size);
> #endif /* CONFIG_MEMORY_HOTPLUG */
>
> +#ifdef CONFIG_MHP_MEMMAP_ON_MEMORY
> +extern bool memmap_on_memory;
> +static inline unsigned long get_memmap_on_memory_flags(void)
> +{
> + if (memmap_on_memory)
> + return MHP_MEMMAP_ON_MEMORY;
> + return 0;
> +}
> +#else
> +static inline unsigned long get_memmap_on_memory_flags(void)
> +{
> + return 0;
> +}
> +#endif
That's kind-of ugly TBH.
Why do we need this change?
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2023-07-06 9:25 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-06 8:50 [PATCH v2 0/5] Add support for memmap on memory feature on ppc64 Aneesh Kumar K.V
2023-07-06 8:50 ` Aneesh Kumar K.V
2023-07-06 8:50 ` [PATCH v2 1/5] mm/hotplug: Embed vmem_altmap details in memory block Aneesh Kumar K.V
2023-07-06 8:50 ` Aneesh Kumar K.V
2023-07-06 9:18 ` David Hildenbrand
2023-07-06 9:18 ` David Hildenbrand
2023-07-06 9:36 ` Aneesh Kumar K V
2023-07-06 9:36 ` Aneesh Kumar K V
2023-07-06 11:14 ` David Hildenbrand
2023-07-06 11:14 ` David Hildenbrand
2023-07-06 12:32 ` Aneesh Kumar K V
2023-07-06 12:32 ` Aneesh Kumar K V
2023-07-06 12:59 ` David Hildenbrand
2023-07-06 12:59 ` David Hildenbrand
2023-07-06 16:06 ` Aneesh Kumar K V
2023-07-06 16:06 ` Aneesh Kumar K V
2023-07-07 12:17 ` David Hildenbrand
2023-07-07 12:17 ` David Hildenbrand
2023-07-07 13:30 ` Aneesh Kumar K V
2023-07-07 13:30 ` Aneesh Kumar K V
2023-07-07 15:42 ` David Hildenbrand
2023-07-07 15:42 ` David Hildenbrand
2023-07-07 16:25 ` Aneesh Kumar K V
2023-07-07 16:25 ` Aneesh Kumar K V
2023-07-07 20:26 ` David Hildenbrand
2023-07-07 20:26 ` David Hildenbrand
2023-07-06 8:50 ` [PATCH v2 2/5] mm/hotplug: Allow architecture override for memmap on memory feature Aneesh Kumar K.V
2023-07-06 8:50 ` Aneesh Kumar K.V
2023-07-06 9:19 ` David Hildenbrand
2023-07-06 9:19 ` David Hildenbrand
2023-07-06 8:50 ` [PATCH v2 3/5] mm/hotplug: Simplify the handling of MHP_MEMMAP_ON_MEMORY flag Aneesh Kumar K.V
2023-07-06 8:50 ` Aneesh Kumar K.V
2023-07-06 9:24 ` David Hildenbrand [this message]
2023-07-06 9:24 ` David Hildenbrand
2023-07-06 10:04 ` Aneesh Kumar K V
2023-07-06 10:04 ` Aneesh Kumar K V
2023-07-06 11:20 ` David Hildenbrand
2023-07-06 11:20 ` David Hildenbrand
2023-07-06 8:50 ` [PATCH v2 4/5] mm/hotplug: Simplify ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE kconfig Aneesh Kumar K.V
2023-07-06 8:50 ` Aneesh Kumar K.V
2023-07-06 8:53 ` David Hildenbrand
2023-07-06 8:53 ` David Hildenbrand
2023-07-06 8:50 ` [PATCH v2 5/5] powerpc/book3s64/memhotplug: Enable memmap on memory for radix Aneesh Kumar K.V
2023-07-06 8:50 ` Aneesh Kumar K.V
2023-07-06 9:07 ` David Hildenbrand
2023-07-06 9:07 ` David Hildenbrand
2023-07-06 9:27 ` Aneesh Kumar K V
2023-07-06 9:27 ` Aneesh Kumar K V
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=0efcd10b-dff8-d011-e192-5feaedc2ee2d@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@suse.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=vishal.l.verma@intel.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 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.