Hotplug memory sources may have opinions on what the memblock size
should be - usually for alignment purposes. For example, CXL memory
extents can be 256MB with a matching alignment. If this size/alignment
is smaller than the block size, it can result in stranded capacity.
Implement memory_block_advise_max_size for use prior to allocator init,
for software to advise the system on the max block size.
Implement memory_block_probe_max_size for use by arch init code to
calculate the best block size. Use of advice is architecture defined.
The probe value can never change after first probe. Calls to advise
after probe will return -EBUSY to aid debugging.
On systems without hotplug, always return -ENODEV and 0 respectively.
Suggested-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Gregory Price <gourry@gourry.net>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
drivers/base/memory.c | 53 ++++++++++++++++++++++++++++++++++++++++++
include/linux/memory.h | 10 ++++++++
2 files changed, 63 insertions(+)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 67858eeb92ed..835793150b41 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -110,6 +110,59 @@ static void memory_block_release(struct device *dev)
kfree(mem);
}
+
+/* Max block size to be set by memory_block_advise_max_size */
+static unsigned long memory_block_advised_size;
+static bool memory_block_advised_size_queried;
+
+/**
+ * memory_block_advise_max_size() - advise memory hotplug on the max suggested
+ * block size, usually for alignment.
+ * @size: suggestion for maximum block size. must be aligned on power of 2.
+ *
+ * Early boot software (pre-allocator init) may advise archs on the max block
+ * size. This value can only decrease after initialization, as the intent is
+ * to identify the largest supported alignment for all sources.
+ *
+ * Use of this value is arch-defined, as is min/max block size.
+ *
+ * Return: 0 on success
+ * -EINVAL if size is 0 or not pow2 aligned
+ * -EBUSY if value has already been probed
+ */
+int __init memory_block_advise_max_size(unsigned long size)
+{
+ if (!size || !is_power_of_2(size))
+ return -EINVAL;
+
+ if (memory_block_advised_size_queried)
+ return -EBUSY;
+
+ if (memory_block_advised_size) {
+ memory_block_advised_size = min(memory_block_advised_size,
+ size);
+ } else {
+ memory_block_advised_size = size;
+ }
+
+ return 0;
+}
+
+/**
+ * memory_block_advised_max_size() - query advised max hotplug block size.
+ *
+ * After the first call, the value can never change. Callers looking for the
+ * actual block size should use memory_block_size_bytes. This interface is
+ * intended for use by arch-init when initializing the hotplug block size.
+ *
+ * Return: advised size in bytes, or 0 if never set.
+ */
+unsigned long memory_block_advised_max_size(void)
+{
+ memory_block_advised_size_queried = true;
+ return memory_block_advised_size;
+}
+
unsigned long __weak memory_block_size_bytes(void)
{
return MIN_MEMORY_BLOCK_SIZE;
diff --git a/include/linux/memory.h b/include/linux/memory.h
index c0afee5d126e..8202d0efbf46 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -149,6 +149,14 @@ static inline int hotplug_memory_notifier(notifier_fn_t fn, int pri)
{
return 0;
}
+static inline int memory_block_advise_max_size(unsigned long size)
+{
+ return -ENODEV;
+}
+static inline unsigned long memory_block_advised_max_size(void)
+{
+ return 0;
+}
#else /* CONFIG_MEMORY_HOTPLUG */
extern int register_memory_notifier(struct notifier_block *nb);
extern void unregister_memory_notifier(struct notifier_block *nb);
@@ -181,6 +189,8 @@ int walk_dynamic_memory_groups(int nid, walk_memory_groups_func_t func,
void memory_block_add_nid(struct memory_block *mem, int nid,
enum meminit_context context);
#endif /* CONFIG_NUMA */
+int memory_block_advise_max_size(unsigned long size);
+unsigned long memory_block_advised_max_size(void);
#endif /* CONFIG_MEMORY_HOTPLUG */
/*
--
2.43.0
Gregory Price wrote: > Hotplug memory sources may have opinions on what the memblock size > should be - usually for alignment purposes. For example, CXL memory > extents can be 256MB with a matching alignment. If this size/alignment > is smaller than the block size, it can result in stranded capacity. > > Implement memory_block_advise_max_size for use prior to allocator init, > for software to advise the system on the max block size. > > Implement memory_block_probe_max_size for use by arch init code to > calculate the best block size. Use of advice is architecture defined. > > The probe value can never change after first probe. Calls to advise > after probe will return -EBUSY to aid debugging. > > On systems without hotplug, always return -ENODEV and 0 respectively. Should the advice just succeed when the result does not matter? Otherwise, it depends on the caller to not care based on config. I do not feel that strongly about it, so either way: Acked-by: Dan Williams <dan.j.williams@intel.com>
On Tue, Nov 12, 2024 at 01:28:03PM -0800, Dan Williams wrote: > Gregory Price wrote: > > Hotplug memory sources may have opinions on what the memblock size > > should be - usually for alignment purposes. For example, CXL memory > > extents can be 256MB with a matching alignment. If this size/alignment > > is smaller than the block size, it can result in stranded capacity. > > > > Implement memory_block_advise_max_size for use prior to allocator init, > > for software to advise the system on the max block size. > > > > Implement memory_block_probe_max_size for use by arch init code to > > calculate the best block size. Use of advice is architecture defined. > > > > The probe value can never change after first probe. Calls to advise > > after probe will return -EBUSY to aid debugging. > > > > On systems without hotplug, always return -ENODEV and 0 respectively. > > Should the advice just succeed when the result does not matter? > I figure at some point during __init the value will be probed and subsequent calls will be ignored. I'd rather fail explicitly in that case to assist debugging - otherwise it might be a little maddening to discover your callsite is too late in the process. > Otherwise, it depends on the caller to not care based on config. > > I do not feel that strongly about it, so either way: > > Acked-by: Dan Williams <dan.j.williams@intel.com>
© 2016 - 2024 Red Hat, Inc.