diff mbox series

[v3,3/3] acpi,srat: give memory block size advice based on CFMWS alignment

Message ID 20241022213450.15041-4-gourry@gourry.net (mailing list archive)
State Handled Elsewhere, archived
Headers show
Series memory,x86,acpi: hotplug memory alignment advisement | expand

Commit Message

Gregory Price Oct. 22, 2024, 9:34 p.m. UTC
Capacity is stranded when CFMWS regions are not aligned to block size.
On x86, block size increases with capacity (2G blocks @ 64G capacity).

Use CFMWS base/size to report memory block size alignment advice.

After the alignment, the acpi code begins populating numa nodes with
memblocks, so probe the value just prior to lock it in.  All future
callers should be providing advice prior to this point.

Suggested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Gregory Price <gourry@gourry.net>
---
 drivers/acpi/numa/srat.c | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

Comments

Mike Rapoport Oct. 28, 2024, 5:24 p.m. UTC | #1
On Tue, Oct 22, 2024 at 05:34:50PM -0400, Gregory Price wrote:
> Capacity is stranded when CFMWS regions are not aligned to block size.
> On x86, block size increases with capacity (2G blocks @ 64G capacity).
> 
> Use CFMWS base/size to report memory block size alignment advice.
> 
> After the alignment, the acpi code begins populating numa nodes with
> memblocks, so probe the value just prior to lock it in.  All future
> callers should be providing advice prior to this point.
> 
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Gregory Price <gourry@gourry.net>
> ---
>  drivers/acpi/numa/srat.c | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 44f91f2c6c5d..35e6f7c17f60 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -14,6 +14,7 @@
>  #include <linux/errno.h>
>  #include <linux/acpi.h>
>  #include <linux/memblock.h>
> +#include <linux/memory.h>
>  #include <linux/numa.h>
>  #include <linux/nodemask.h>
>  #include <linux/topology.h>
> @@ -333,6 +334,29 @@ acpi_parse_memory_affinity(union acpi_subtable_headers *header,
>  	return 0;
>  }
>  
> +/* Advise memblock on maximum block size to avoid stranded capacity. */
> +static int __init acpi_align_cfmws(union acpi_subtable_headers *header,
> +				   void *arg, const unsigned long table_end)
> +{
> +	struct acpi_cedt_cfmws *cfmws = (struct acpi_cedt_cfmws *)header;
> +	u64 start = cfmws->base_hpa;
> +	u64 size = cfmws->window_size;
> +	unsigned long bz;

Maybe unsigned long size?

> +
> +	for (bz = SZ_64T; bz >= SZ_256M; bz >>= 1) {
> +		if (IS_ALIGNED(start, bz) && IS_ALIGNED(size, bz))
> +			break;
> +	}
> +
> +	if (bz >= SZ_256M) {
> +		if (memory_block_advise_max_size(bz) < 0)
> +			pr_warn("CFMWS: memblock size advise failed\n");
> +	} else

Nit: braces needed for else arm as well

> +		pr_err("CFMWS: [BIOS BUG] base/size alignment violates spec\n");
> +
> +	return 0;
> +}
> +
>  static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  				   void *arg, const unsigned long table_end)
>  {
> @@ -545,6 +569,15 @@ int __init acpi_numa_init(void)
>  	 * Initialize a fake_pxm as the first available PXM to emulate.
>  	 */
>  
> +	/* Align memblock size to CFMW regions if possible */
> +	acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_align_cfmws, NULL);
> +
> +	/*
> +	 * Nodes start populating with blocks after this, so probe the max
> +	 * block size to prevent it from changing in the future.
> +	 */
> +	memory_block_probe_max_size();
> +

It won't change, but how drivers/base/memory.c will know about the probed
size if architecture does not override memory_block_size_bytes()?

>  	/* fake_pxm is the next unused PXM value after SRAT parsing */
>  	for (i = 0, fake_pxm = -1; i < MAX_NUMNODES; i++) {
>  		if (node_to_pxm_map[i] > fake_pxm)
> -- 
> 2.43.0
>
Gregory Price Oct. 28, 2024, 8:55 p.m. UTC | #2
On Mon, Oct 28, 2024 at 07:24:54PM +0200, Mike Rapoport wrote:
> On Tue, Oct 22, 2024 at 05:34:50PM -0400, Gregory Price wrote:
> > Capacity is stranded when CFMWS regions are not aligned to block size.
> > On x86, block size increases with capacity (2G blocks @ 64G capacity).
> > 
> > Use CFMWS base/size to report memory block size alignment advice.
> > 
> > After the alignment, the acpi code begins populating numa nodes with
> > memblocks, so probe the value just prior to lock it in.  All future
> > callers should be providing advice prior to this point.
> > 
> > Suggested-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Gregory Price <gourry@gourry.net>
> > ---
> >  drivers/acpi/numa/srat.c | 33 +++++++++++++++++++++++++++++++++
> >  1 file changed, 33 insertions(+)
> > 
... snip ...
> > +	/* Align memblock size to CFMW regions if possible */
> > +	acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_align_cfmws, NULL);
> > +
> > +	/*
> > +	 * Nodes start populating with blocks after this, so probe the max
> > +	 * block size to prevent it from changing in the future.
> > +	 */
> > +	memory_block_probe_max_size();
> > +
> 
> It won't change, but how drivers/base/memory.c will know about the probed
> size if architecture does not override memory_block_size_bytes()?
> 

non-arch code should be calling memory_block_size_bytes() to discover
the actual size of blocks - and for archs that care about this value,
that is when it should be probed.  It's up to the arch whether/how to use
this information.  Many archs ignore it entirely and use MIN_BLOCK_SIZE.

basically non-arch code shouldn't care what this value is, and even most
arch code shouldn't care.


I added this call to probe to lock in the size since I saw that nodes
will start populating blocks immediately after this.

Possibly the APIs should be marked __init so that the whole interface
disappears after init to avoid misuse post-init.

Possibly probe() should return -EBUSY if called more than once to
enforce a particular probe pattern on the architectures?

Open to thoughts here.

> >  	/* fake_pxm is the next unused PXM value after SRAT parsing */
> >  	for (i = 0, fake_pxm = -1; i < MAX_NUMNODES; i++) {
> >  		if (node_to_pxm_map[i] > fake_pxm)
> > -- 
> > 2.43.0
> > 
> 
> -- 
> Sincerely yours,
> Mike.
David Hildenbrand Oct. 29, 2024, 12:42 p.m. UTC | #3
>   static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>   				   void *arg, const unsigned long table_end)
>   {
> @@ -545,6 +569,15 @@ int __init acpi_numa_init(void)
>   	 * Initialize a fake_pxm as the first available PXM to emulate.
>   	 */
>   
> +	/* Align memblock size to CFMW regions if possible */
> +	acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_align_cfmws, NULL);
> +
> +	/*
> +	 * Nodes start populating with blocks after this, so probe the max
> +	 * block size to prevent it from changing in the future.
> +	 */
> +	memory_block_probe_max_size();
> +

This looks odd. Why shouldn't we allow someone else to suggest/advise an 
even smaller "max size" ? I'd drop that.
Gregory Price Oct. 29, 2024, 1:20 p.m. UTC | #4
On Tue, Oct 29, 2024 at 01:42:12PM +0100, David Hildenbrand wrote:
> 
> >   static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> >   				   void *arg, const unsigned long table_end)
> >   {
> > @@ -545,6 +569,15 @@ int __init acpi_numa_init(void)
> >   	 * Initialize a fake_pxm as the first available PXM to emulate.
> >   	 */
> > +	/* Align memblock size to CFMW regions if possible */
> > +	acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_align_cfmws, NULL);
> > +
> > +	/*
> > +	 * Nodes start populating with blocks after this, so probe the max
> > +	 * block size to prevent it from changing in the future.
> > +	 */
> > +	memory_block_probe_max_size();
> > +
> 
> This looks odd. Why shouldn't we allow someone else to suggest/advise an
> even smaller "max size" ? I'd drop that.
> 

Ah, my reading of the numa_add_memblk path was mistaken.  I thought the
hotplug blocks would start being created immediately after this in the
acpi_parse_cfmws path - but memblk != memory_block x_x.

Will drop along with other recommended updates and submit v4.

~Gregory
Mike Rapoport Oct. 29, 2024, 4:31 p.m. UTC | #5
On Tue, Oct 29, 2024 at 09:20:44AM -0400, Gregory Price wrote:
> On Tue, Oct 29, 2024 at 01:42:12PM +0100, David Hildenbrand wrote:
> > 
> > >   static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> > >   				   void *arg, const unsigned long table_end)
> > >   {
> > > @@ -545,6 +569,15 @@ int __init acpi_numa_init(void)
> > >   	 * Initialize a fake_pxm as the first available PXM to emulate.
> > >   	 */
> > > +	/* Align memblock size to CFMW regions if possible */
> > > +	acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_align_cfmws, NULL);
> > > +
> > > +	/*
> > > +	 * Nodes start populating with blocks after this, so probe the max
> > > +	 * block size to prevent it from changing in the future.
> > > +	 */
> > > +	memory_block_probe_max_size();
> > > +
> > 
> > This looks odd. Why shouldn't we allow someone else to suggest/advise an
> > even smaller "max size" ? I'd drop that.
> > 
> 
> Ah, my reading of the numa_add_memblk path was mistaken.  I thought the
> hotplug blocks would start being created immediately after this in the
> acpi_parse_cfmws path - but memblk != memory_block x_x.

Right, we have a bunch of semi related memory blocks :)

There's mm/memblock.c for early memory description and allocation,
mm/numa_memblks.c for to describe what range belongs to which NUMA node and
there are memory blocks in drivers/base/memory.c that describe
hot-(un)plugable memory blocks.

Maybe it's time to rename memblock_* APIs back to bootmem_ :-D
 
> Will drop along with other recommended updates and submit v4.
> 
> ~Gregory
diff mbox series

Patch

diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index 44f91f2c6c5d..35e6f7c17f60 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -14,6 +14,7 @@ 
 #include <linux/errno.h>
 #include <linux/acpi.h>
 #include <linux/memblock.h>
+#include <linux/memory.h>
 #include <linux/numa.h>
 #include <linux/nodemask.h>
 #include <linux/topology.h>
@@ -333,6 +334,29 @@  acpi_parse_memory_affinity(union acpi_subtable_headers *header,
 	return 0;
 }
 
+/* Advise memblock on maximum block size to avoid stranded capacity. */
+static int __init acpi_align_cfmws(union acpi_subtable_headers *header,
+				   void *arg, const unsigned long table_end)
+{
+	struct acpi_cedt_cfmws *cfmws = (struct acpi_cedt_cfmws *)header;
+	u64 start = cfmws->base_hpa;
+	u64 size = cfmws->window_size;
+	unsigned long bz;
+
+	for (bz = SZ_64T; bz >= SZ_256M; bz >>= 1) {
+		if (IS_ALIGNED(start, bz) && IS_ALIGNED(size, bz))
+			break;
+	}
+
+	if (bz >= SZ_256M) {
+		if (memory_block_advise_max_size(bz) < 0)
+			pr_warn("CFMWS: memblock size advise failed\n");
+	} else
+		pr_err("CFMWS: [BIOS BUG] base/size alignment violates spec\n");
+
+	return 0;
+}
+
 static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
 				   void *arg, const unsigned long table_end)
 {
@@ -545,6 +569,15 @@  int __init acpi_numa_init(void)
 	 * Initialize a fake_pxm as the first available PXM to emulate.
 	 */
 
+	/* Align memblock size to CFMW regions if possible */
+	acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_align_cfmws, NULL);
+
+	/*
+	 * Nodes start populating with blocks after this, so probe the max
+	 * block size to prevent it from changing in the future.
+	 */
+	memory_block_probe_max_size();
+
 	/* fake_pxm is the next unused PXM value after SRAT parsing */
 	for (i = 0, fake_pxm = -1; i < MAX_NUMNODES; i++) {
 		if (node_to_pxm_map[i] > fake_pxm)