From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: David Hildenbrand <david@redhat.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 v3 4/7] mm/hotplug: Allow pageblock alignment via altmap reservation
Date: Wed, 12 Jul 2023 19:20:14 +0530 [thread overview]
Message-ID: <87wmz56xyh.fsf@linux.ibm.com> (raw)
In-Reply-To: <57dd0568-ee56-ff8d-3ba3-a9089a2ab386@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 12.07.23 05:16, Aneesh Kumar K V wrote:
>> On 7/11/23 10:49 PM, David Hildenbrand wrote:
>>> On 11.07.23 06:48, Aneesh Kumar K.V wrote:
>>>> Add a new kconfig option that can be selected if we want to allow
>>>> pageblock alignment by reserving pages in the vmemmap altmap area.
>>>> This implies we will be reserving some pages for every memoryblock
>>>> This also allows the memmap on memory feature to be widely useful
>>>> with different memory block size values.
>>>
>>> "reserving pages" is a nice way of saying "wasting memory". :) Let's spell that out.
>>>
>>> I think we have to find a better name for this, and I think we should have a toggle similar to memory_hotplug.memmap_on_memory. This should be an admin decision, not some kernel config option.
>>>
>>>
>>> memory_hotplug.force_memmap_on_memory
>>>
>>> "Enable the memmap on memory feature even if it could result in memory waste due to memmap size limitations. For example, if the memmap for a memory block requires 1 MiB, but the pageblock size is 2 MiB, 1 MiB
>>> of hotplugged memory will be wasted. Note that there are still cases where the feature cannot be enforced: for example, if the memmap is smaller than a single page, or if the architecture does not support the forced mode in all configurations."
>>>
>>> Thoughts?
>>>
>>
>> With module parameter, do we still need the Kconfig option?
>
> No.
>
> Sleeping over this, maybe we can convert the existing
> memory_hotplug.memmap_on_memory parameter to also accept "force".
>
How about this?
modified mm/memory_hotplug.c
@@ -45,13 +45,67 @@
/*
* 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");
+enum {
+ MEMMAP_ON_MEMORY_DISABLE = 0,
+ MEMMAP_ON_MEMORY_ENABLE,
+ FORCE_MEMMAP_ON_MEMORY,
+};
+static int memmap_mode __read_mostly = MEMMAP_ON_MEMORY_DISABLE;
+static const char *memmap_on_memory_to_str[] = {
+ [MEMMAP_ON_MEMORY_DISABLE] = "disable",
+ [MEMMAP_ON_MEMORY_ENABLE] = "enable",
+ [FORCE_MEMMAP_ON_MEMORY] = "force",
+};
+
+static inline unsigned long memory_block_align_base(unsigned long size)
+{
+ if (memmap_mode == FORCE_MEMMAP_ON_MEMORY) {
+ unsigned long align;
+ unsigned long nr_vmemmap_pages = size >> PAGE_SHIFT;
+ unsigned long vmemmap_size;
+
+ vmemmap_size = DIV_ROUND_UP(nr_vmemmap_pages * sizeof(struct page), PAGE_SIZE);
+ align = pageblock_align(vmemmap_size) - vmemmap_size;
+ return align;
+ } else
+ return 0;
+}
+
+static int set_memmap_mode(const char *val, const struct kernel_param *kp)
+{
+ int ret = sysfs_match_string(memmap_on_memory_to_str, val);
+
+ if (ret < 0)
+ return ret;
+ *((int *)kp->arg) = ret;
+ if (ret == FORCE_MEMMAP_ON_MEMORY) {
+ pr_info("Memory hotplug will reserve %ld pages in each memory block\n",
+ memory_block_align_base(memory_block_size_bytes()));
+ }
+ return 0;
+}
+
+static int get_memmap_mode(char *buffer, const struct kernel_param *kp)
+{
+ return sprintf(buffer, "%s\n", memmap_on_memory_to_str[*((int *)kp->arg)]);
+}
+
+static const struct kernel_param_ops memmap_mode_ops = {
+ .set = set_memmap_mode,
+ .get = get_memmap_mode,
+};
+module_param_cb(memmap_on_memory, &memmap_mode_ops, &memmap_mode, 0644);
+MODULE_PARM_DESC(memmap_on_memory, "Enable memmap on memory for memory hotplug\n"
+ "With value \"force\" it could result in memory waste due to memmap size limitations \n"
+ "For example, if the memmap for a memory block requires 1 MiB, but the pageblock \n"
+ "size is 2 MiB, 1 MiB of hotplugged memory will be wasted. Note that there are \n"
+ "still cases where the feature cannot be enforced: for example, if the memmap is \n"
+ "smaller than a single page, or if the architecture does not support the forced \n"
+ "mode in all configurations. (disable/enable/force)");
static inline bool mhp_memmap_on_memory(void)
{
- return memmap_on_memory;
+ return !!memmap_mode;
}
#else
We can also enable runtime enable/disable/force the feature. We just
need to make sure on try_remove_memory we lookup for altmap correctly.
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: David Hildenbrand <david@redhat.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 v3 4/7] mm/hotplug: Allow pageblock alignment via altmap reservation
Date: Wed, 12 Jul 2023 19:20:14 +0530 [thread overview]
Message-ID: <87wmz56xyh.fsf@linux.ibm.com> (raw)
In-Reply-To: <57dd0568-ee56-ff8d-3ba3-a9089a2ab386@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 12.07.23 05:16, Aneesh Kumar K V wrote:
>> On 7/11/23 10:49 PM, David Hildenbrand wrote:
>>> On 11.07.23 06:48, Aneesh Kumar K.V wrote:
>>>> Add a new kconfig option that can be selected if we want to allow
>>>> pageblock alignment by reserving pages in the vmemmap altmap area.
>>>> This implies we will be reserving some pages for every memoryblock
>>>> This also allows the memmap on memory feature to be widely useful
>>>> with different memory block size values.
>>>
>>> "reserving pages" is a nice way of saying "wasting memory". :) Let's spell that out.
>>>
>>> I think we have to find a better name for this, and I think we should have a toggle similar to memory_hotplug.memmap_on_memory. This should be an admin decision, not some kernel config option.
>>>
>>>
>>> memory_hotplug.force_memmap_on_memory
>>>
>>> "Enable the memmap on memory feature even if it could result in memory waste due to memmap size limitations. For example, if the memmap for a memory block requires 1 MiB, but the pageblock size is 2 MiB, 1 MiB
>>> of hotplugged memory will be wasted. Note that there are still cases where the feature cannot be enforced: for example, if the memmap is smaller than a single page, or if the architecture does not support the forced mode in all configurations."
>>>
>>> Thoughts?
>>>
>>
>> With module parameter, do we still need the Kconfig option?
>
> No.
>
> Sleeping over this, maybe we can convert the existing
> memory_hotplug.memmap_on_memory parameter to also accept "force".
>
How about this?
modified mm/memory_hotplug.c
@@ -45,13 +45,67 @@
/*
* 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");
+enum {
+ MEMMAP_ON_MEMORY_DISABLE = 0,
+ MEMMAP_ON_MEMORY_ENABLE,
+ FORCE_MEMMAP_ON_MEMORY,
+};
+static int memmap_mode __read_mostly = MEMMAP_ON_MEMORY_DISABLE;
+static const char *memmap_on_memory_to_str[] = {
+ [MEMMAP_ON_MEMORY_DISABLE] = "disable",
+ [MEMMAP_ON_MEMORY_ENABLE] = "enable",
+ [FORCE_MEMMAP_ON_MEMORY] = "force",
+};
+
+static inline unsigned long memory_block_align_base(unsigned long size)
+{
+ if (memmap_mode == FORCE_MEMMAP_ON_MEMORY) {
+ unsigned long align;
+ unsigned long nr_vmemmap_pages = size >> PAGE_SHIFT;
+ unsigned long vmemmap_size;
+
+ vmemmap_size = DIV_ROUND_UP(nr_vmemmap_pages * sizeof(struct page), PAGE_SIZE);
+ align = pageblock_align(vmemmap_size) - vmemmap_size;
+ return align;
+ } else
+ return 0;
+}
+
+static int set_memmap_mode(const char *val, const struct kernel_param *kp)
+{
+ int ret = sysfs_match_string(memmap_on_memory_to_str, val);
+
+ if (ret < 0)
+ return ret;
+ *((int *)kp->arg) = ret;
+ if (ret == FORCE_MEMMAP_ON_MEMORY) {
+ pr_info("Memory hotplug will reserve %ld pages in each memory block\n",
+ memory_block_align_base(memory_block_size_bytes()));
+ }
+ return 0;
+}
+
+static int get_memmap_mode(char *buffer, const struct kernel_param *kp)
+{
+ return sprintf(buffer, "%s\n", memmap_on_memory_to_str[*((int *)kp->arg)]);
+}
+
+static const struct kernel_param_ops memmap_mode_ops = {
+ .set = set_memmap_mode,
+ .get = get_memmap_mode,
+};
+module_param_cb(memmap_on_memory, &memmap_mode_ops, &memmap_mode, 0644);
+MODULE_PARM_DESC(memmap_on_memory, "Enable memmap on memory for memory hotplug\n"
+ "With value \"force\" it could result in memory waste due to memmap size limitations \n"
+ "For example, if the memmap for a memory block requires 1 MiB, but the pageblock \n"
+ "size is 2 MiB, 1 MiB of hotplugged memory will be wasted. Note that there are \n"
+ "still cases where the feature cannot be enforced: for example, if the memmap is \n"
+ "smaller than a single page, or if the architecture does not support the forced \n"
+ "mode in all configurations. (disable/enable/force)");
static inline bool mhp_memmap_on_memory(void)
{
- return memmap_on_memory;
+ return !!memmap_mode;
}
#else
We can also enable runtime enable/disable/force the feature. We just
need to make sure on try_remove_memory we lookup for altmap correctly.
next prev parent reply other threads:[~2023-07-12 13:51 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 4:48 [PATCH v3 0/7] Add support for memmap on memory feature on ppc64 Aneesh Kumar K.V
2023-07-11 4:48 ` Aneesh Kumar K.V
2023-07-11 4:48 ` [PATCH v3 1/7] mm/hotplug: Simplify ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE kconfig Aneesh Kumar K.V
2023-07-11 4:48 ` Aneesh Kumar K.V
2023-07-11 4:48 ` [PATCH v3 2/7] mm/hotplug: Allow memmap on memory hotplug request to fallback Aneesh Kumar K.V
2023-07-11 4:48 ` Aneesh Kumar K.V
2023-07-11 10:23 ` David Hildenbrand
2023-07-11 10:23 ` David Hildenbrand
2023-07-11 15:58 ` Aneesh Kumar K V
2023-07-11 15:58 ` Aneesh Kumar K V
2023-07-11 4:48 ` [PATCH v3 3/7] mm/hotplug: Allow architecture to override memmap on memory support check Aneesh Kumar K.V
2023-07-11 4:48 ` Aneesh Kumar K.V
2023-07-11 10:36 ` David Hildenbrand
2023-07-11 10:36 ` David Hildenbrand
2023-07-11 16:07 ` Aneesh Kumar K V
2023-07-11 16:07 ` Aneesh Kumar K V
2023-07-11 16:09 ` David Hildenbrand
2023-07-11 16:09 ` David Hildenbrand
2023-07-12 20:07 ` John Hubbard
2023-07-12 20:07 ` John Hubbard
2023-07-13 9:08 ` David Hildenbrand
2023-07-13 9:08 ` David Hildenbrand
2023-07-14 23:14 ` John Hubbard
2023-07-14 23:14 ` John Hubbard
2023-07-11 4:48 ` [PATCH v3 4/7] mm/hotplug: Allow pageblock alignment via altmap reservation Aneesh Kumar K.V
2023-07-11 4:48 ` Aneesh Kumar K.V
2023-07-11 6:21 ` Huang, Ying
2023-07-11 6:21 ` Huang, Ying
2023-07-11 8:20 ` Aneesh Kumar K V
2023-07-11 8:20 ` Aneesh Kumar K V
2023-07-11 17:19 ` David Hildenbrand
2023-07-11 17:19 ` David Hildenbrand
2023-07-12 3:16 ` Aneesh Kumar K V
2023-07-12 3:16 ` Aneesh Kumar K V
2023-07-12 7:22 ` David Hildenbrand
2023-07-12 7:22 ` David Hildenbrand
2023-07-12 13:50 ` Aneesh Kumar K.V [this message]
2023-07-12 13:50 ` Aneesh Kumar K.V
2023-07-12 19:06 ` David Hildenbrand
2023-07-12 19:06 ` David Hildenbrand
2023-07-11 4:48 ` [PATCH v3 5/7] powerpc/book3s64/memhotplug: Enable memmap on memory for radix Aneesh Kumar K.V
2023-07-11 4:48 ` Aneesh Kumar K.V
2023-07-11 15:26 ` David Hildenbrand
2023-07-11 15:26 ` David Hildenbrand
2023-07-11 15:40 ` Aneesh Kumar K V
2023-07-11 15:40 ` Aneesh Kumar K V
2023-07-11 15:44 ` David Hildenbrand
2023-07-11 15:44 ` David Hildenbrand
2023-07-11 15:46 ` Aneesh Kumar K V
2023-07-11 15:46 ` Aneesh Kumar K V
2023-07-11 4:48 ` [PATCH v3 6/7] dax/kmem: Always enroll hotplugged memory for memmap_on_memory Aneesh Kumar K.V
2023-07-11 4:48 ` Aneesh Kumar K.V
2023-07-11 10:21 ` David Hildenbrand
2023-07-11 10:21 ` David Hildenbrand
2023-07-11 4:48 ` [PATCH v3 7/7] mm/hotplug: Embed vmem_altmap details in memory block Aneesh Kumar K.V
2023-07-11 4:48 ` 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=87wmz56xyh.fsf@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=christophe.leroy@csgroup.eu \
--cc=david@redhat.com \
--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.