| Message ID | 20250506062245.3816791-1-wangyuquan1236@phytium.com.cn |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] mm: numa_memblks: introduce numa_add_reserved_memblk | expand |
On Tue, May 06, 2025 at 06:55:44PM -0700, Andrew Morton wrote: > On Tue, 6 May 2025 14:22:45 +0800 Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote: > > > 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 support of future hotplug / CXL provisioning. > > > > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS > > ranges directly. > > > > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn> > > --- > > > > Changes in v2 (Thanks to Dan & Alison): > > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws() > > - Add comments to describe the usage of numa_add_reserved_memblk() > > - Updating the commit message to clarify the purpose of the patch > > > > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next. > > So is this patch dependent upon "LoongArch: Introduce the numa_memblks > conversion"? Yes, the previous version of this patch failed to build on loongarch.
On Wed, May 07, 2025 at 05:24:36PM +0100, Jonathan Cameron wrote: > On Tue, 6 May 2025 14:22:45 +0800 > Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote: > > > 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 support of future hotplug / CXL provisioning. > > > > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS > > ranges directly. > > > > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn> > This is v2 take 2. There were tags on the previous version (pre longarch > change). > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > (Also Dan Williams). > > Easiest option when this happens is spin a v3 with a change log to > say the loongarch issue is resolved and you picked up tags. > Hi Jonathan, Thanks for your tips. Would this v2 version trigger the kernel test robot? It seems like only a new version of patch would trigger that. I would publish v3 of this patch as soon as possible. Yuquan > > > --- > > > > Changes in v2 (Thanks to Dan & Alison): > > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws() > > - Add comments to describe the usage of numa_add_reserved_memblk() > > - Updating the commit message to clarify the purpose of the patch > > > > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next. > > > > drivers/acpi/numa/srat.c | 2 +- > > include/linux/numa_memblks.h | 1 + > > mm/numa_memblks.c | 22 ++++++++++++++++++++++ > > 3 files changed, 24 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c > > index 0a725e46d017..751774f0b4e5 100644 > > --- a/drivers/acpi/numa/srat.c > > +++ b/drivers/acpi/numa/srat.c > > @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header, > > return -EINVAL; > > } > > > > - if (numa_add_memblk(node, start, end) < 0) { > > + if (numa_add_reserved_memblk(node, start, end) < 0) { > > /* CXL driver must handle the NUMA_NO_NODE case */ > > pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n", > > node, start, end); > > 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..541a99c4071a 100644 > > --- a/mm/numa_memblks.c > > +++ b/mm/numa_memblks.c > > @@ -200,6 +200,28 @@ 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. > > + * > > + * Usage Case: 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, we use numa_add_reserved_memblk() to add the numa_memblk > > + * to numa_reserved_meminfo directly. > > + * > > + * 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 >
On Thu, May 8, 2025 at 9:47 AM Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote: > > On Wed, May 07, 2025 at 05:24:36PM +0100, Jonathan Cameron wrote: > > On Tue, 6 May 2025 14:22:45 +0800 > > Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote: > > > > > 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 support of future hotplug / CXL provisioning. > > > > > > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS > > > ranges directly. > > > > > > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn> > > This is v2 take 2. There were tags on the previous version (pre longarch > > change). > > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > (Also Dan Williams). > > > > Easiest option when this happens is spin a v3 with a change log to > > say the loongarch issue is resolved and you picked up tags. > > > Hi Jonathan, > > Thanks for your tips. Would this v2 version trigger the kernel test > robot? It seems like only a new version of patch would trigger that. > I would publish v3 of this patch as soon as possible. The kernel test robot operates on linux-next, so there's probably no errors now. Huacai > > Yuquan > > > > > --- > > > > > > Changes in v2 (Thanks to Dan & Alison): > > > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws() > > > - Add comments to describe the usage of numa_add_reserved_memblk() > > > - Updating the commit message to clarify the purpose of the patch > > > > > > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next. > > > > > > drivers/acpi/numa/srat.c | 2 +- > > > include/linux/numa_memblks.h | 1 + > > > mm/numa_memblks.c | 22 ++++++++++++++++++++++ > > > 3 files changed, 24 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c > > > index 0a725e46d017..751774f0b4e5 100644 > > > --- a/drivers/acpi/numa/srat.c > > > +++ b/drivers/acpi/numa/srat.c > > > @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header, > > > return -EINVAL; > > > } > > > > > > - if (numa_add_memblk(node, start, end) < 0) { > > > + if (numa_add_reserved_memblk(node, start, end) < 0) { > > > /* CXL driver must handle the NUMA_NO_NODE case */ > > > pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n", > > > node, start, end); > > > 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..541a99c4071a 100644 > > > --- a/mm/numa_memblks.c > > > +++ b/mm/numa_memblks.c > > > @@ -200,6 +200,28 @@ 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. > > > + * > > > + * Usage Case: 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, we use numa_add_reserved_memblk() to add the numa_memblk > > > + * to numa_reserved_meminfo directly. > > > + * > > > + * 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 > > >
diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c index 0a725e46d017..751774f0b4e5 100644 --- a/drivers/acpi/numa/srat.c +++ b/drivers/acpi/numa/srat.c @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header, return -EINVAL; } - if (numa_add_memblk(node, start, end) < 0) { + if (numa_add_reserved_memblk(node, start, end) < 0) { /* CXL driver must handle the NUMA_NO_NODE case */ pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n", node, start, end); 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..541a99c4071a 100644 --- a/mm/numa_memblks.c +++ b/mm/numa_memblks.c @@ -200,6 +200,28 @@ 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. + * + * Usage Case: 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, we use numa_add_reserved_memblk() to add the numa_memblk + * to numa_reserved_meminfo directly. + * + * 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
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 support of future hotplug / CXL provisioning. Introduce and use numa_add_reserved_memblk() to add the empty CFMWS ranges directly. Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn> --- Changes in v2 (Thanks to Dan & Alison): - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws() - Add comments to describe the usage of numa_add_reserved_memblk() - Updating the commit message to clarify the purpose of the patch By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next. drivers/acpi/numa/srat.c | 2 +- include/linux/numa_memblks.h | 1 + mm/numa_memblks.c | 22 ++++++++++++++++++++++ 3 files changed, 24 insertions(+), 1 deletion(-)