With numa_add_reserved_memblk(), kernel could add numa_memblk into
numa_reserved_meminfo directly.
In previous, such process relies on numa_add_memblk() adding to
numa_meminfo list first and then uses numa_move_tail_memblk() to
move one from numa_meminfo to numa_reserved_meminfo.
Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
---
include/linux/numa_memblks.h | 1 +
mm/numa_memblks.c | 16 ++++++++++++++++
2 files changed, 17 insertions(+)
diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
index dd85613cdd86..991076cba7c5 100644
--- a/include/linux/numa_memblks.h
+++ b/include/linux/numa_memblks.h
@@ -22,6 +22,7 @@ struct numa_meminfo {
};
int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
index ff4054f4334d..e70c76cc46dd 100644
--- a/mm/numa_memblks.c
+++ b/mm/numa_memblks.c
@@ -200,6 +200,22 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
return numa_add_memblk_to(nid, start, end, &numa_meminfo);
}
+/**
+ * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
+ * @nid: NUMA node ID of the new memblk
+ * @start: Start address of the new memblk
+ * @end: End address of the new memblk
+ *
+ * Add a new memblk to the numa_reserved_meminfo.
+ *
+ * RETURNS:
+ * 0 on success, -errno on failure.
+ */
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
+{
+ return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
+}
+
/**
* numa_cleanup_meminfo - Cleanup a numa_meminfo
* @mi: numa_meminfo to clean up
--
2.34.1
Yuquan Wang wrote:
> With numa_add_reserved_memblk(), kernel could add numa_memblk into
> numa_reserved_meminfo directly.
>
> In previous, such process relies on numa_add_memblk() adding to
> numa_meminfo list first and then uses numa_move_tail_memblk() to
> move one from numa_meminfo to numa_reserved_meminfo.
I would explicitly state the motivation and the use case for the patch.
---
acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
with the expectation that numa_cleanup_meminfo moves them to
numa_reserved_meminfo. There is no need for that indirection when it is
known in advance that these unpopulated ranges are meant for
numa_reserved_meminfo in suppot of future hotplug / CXL provisioning.
---
>
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> ---
> include/linux/numa_memblks.h | 1 +
> mm/numa_memblks.c | 16 ++++++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
> };
>
> int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
> void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>
> int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..e70c76cc46dd 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,22 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
> return numa_add_memblk_to(nid, start, end, &numa_meminfo);
> }
>
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
I would say a bit more here about when to use this function. Something
like:
"numa_cleanup_meminfo() reconciles all numa_memblk instances against
memblock_type information and moves any that intersect reserved ranges
to numa_reserved_meminfo. However, when that information is known ahead
of time add the numa_memblk to numa_reserved_meminfo directly."
With those 2 suggestions you can add:
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
© 2016 - 2025 Red Hat, Inc.