[PATCH v3 0/3] memory,x86,acpi: hotplug memory alignment advisement

[PATCH v3 0/3] memory,x86,acpi: hotplug memory alignment advisement

[Gregory Price]

When physical address regions are not aligned to memory block size,
the misaligned portion is lost (stranded capacity).

Block size (min/max/selected) is architecture defined. Most architectures
tend to use the minimum block size or some simplistic heurist. On x86,
memory block size increases up to 2GB, and is otherwise fitted to the
alignment of non-hotplug (special purpose memory).

CXL exposes its memory for management through the ACPI CEDT (CXL Early
Detection Table) in a field called the CXL Fixed Memory Window.  Per
the CXL specification, this memory must be aligned to at least 256MB.

When a CFMW aligns on a size less than the block size, this causes a
loss of up to 2GB per CFMW on x86.  It is not uncommon for CFMW to be
allocated per-device - though this behavior is BIOS defined.

This patch set provides 3 things:
 1) implement advise/probe functions in driverse/base/memory.c to
    report/probe architecture agnostic hotplug memory alignment advice.
 2) update x86 memblock size logic to consider the hotplug advice
 3) add code in acpi/numa/srat.c to report CFMW alignment advice

The advisement interfaces are design to be called during arch_init
code prior to allocator and smp_init.  start_kernel will call these
through setup_arch() (via acpi and mm/init_64.c on x86), which occurs
prior to mm_core_init and smp_init - so no need for atomics.

There's an attempt to signal callers to advise() that probe has already
occurred, but this is predicated on the notion that probe() actually
occurs (which presently only happens on x86 and acpi logic).
This is to assist debugging future users.

Once probe is called the first time, it will always return the same value.

Interfaces return -EBUSY and 0 respectively on systems without hotplug.

Suggested-by: Ira Weiny <ira.weiny@intel.com>
Suggested-by: David Hildenbrand <david@redhat.com>
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Gregory Price <gourry@gourry.net>

Gregory Price (3):
  memory: implement memory_block_advise/probe_max_size
  x86: probe memory block size advisement value during mm init
  acpi,srat: give memory block size advice based on CFMWS alignment

 arch/x86/mm/init_64.c    | 14 ++++++++-----
 drivers/acpi/numa/srat.c | 33 ++++++++++++++++++++++++++++++
 drivers/base/memory.c    | 43 ++++++++++++++++++++++++++++++++++++++++
 include/linux/memory.h   | 10 ++++++++++
 4 files changed, 95 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH v3 1/3] memory: implement memory_block_advise/probe_max_size

[Gregory Price]

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>
---
 drivers/base/memory.c  | 43 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/memory.h | 10 ++++++++++
 2 files changed, 53 insertions(+)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 67858eeb92ed..a0fd9e1451aa 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -110,6 +110,49 @@ static void memory_block_release(struct device *dev)
 	kfree(mem);
 }
 
+/*
+ * @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 dependent, as is min/max block size.
+ *
+ * Returns: 0 on success
+ *	    -EINVAL if size is 0 or not pow2 aligned
+ *	    -EBUSY if value has already been probed
+ */
+static size_t memory_block_advised_sz;
+static bool memory_block_size_probed;
+int memory_block_advise_max_size(size_t bz)
+{
+	if (!bz || (bz & (bz - 1)) != 0)
+		return -EINVAL;
+
+	if (memory_block_size_probed)
+		return -EBUSY;
+
+	if (memory_block_advised_sz)
+		memory_block_advised_sz = min(bz, memory_block_advised_sz);
+	else
+		memory_block_advised_sz = bz;
+
+	return 0;
+}
+
+/*
+ * memory_block_probe_max_size provides a suggested maximum memory block
+ * size value. After the first call, the value can never change.
+ *
+ * Returns: advised size in bytes, or 0 if never set.
+ */
+size_t memory_block_probe_max_size(void)
+{
+	memory_block_size_probed = true;
+	return memory_block_advised_sz;
+}
+
 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..47c00d6e1165 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(size_t size)
+{
+	return -ENODEV;
+}
+static inline size_t memory_block_probe_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(size_t size);
+size_t memory_block_probe_max_size(void);
 #endif	/* CONFIG_MEMORY_HOTPLUG */
 
 /*
-- 
2.43.0

Re: [PATCH v3 1/3] memory: implement memory_block_advise/probe_max_size

[Mike Rapoport]

Hi,

On Tue, Oct 22, 2024 at 05:34:48PM -0400, 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.
> 
> Suggested-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Gregory Price <gourry@gourry.net>
> ---
>  drivers/base/memory.c  | 43 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/memory.h | 10 ++++++++++
>  2 files changed, 53 insertions(+)
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 67858eeb92ed..a0fd9e1451aa 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -110,6 +110,49 @@ static void memory_block_release(struct device *dev)
>  	kfree(mem);
>  }
>  
> +/*

If the intention for this to be a kernel-doc comment it should start with
/**, should be placed right before the documented function and start with a
brief function description

> + * @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 dependent, as is min/max block size.
> + *
> + * Returns: 0 on success
> + *	    -EINVAL if size is 0 or not pow2 aligned
> + *	    -EBUSY if value has already been probed
> + */
> +static size_t memory_block_advised_sz;
> +static bool memory_block_size_probed;
> +int memory_block_advise_max_size(size_t bz)

size seems to me a better parameter name :)

> +{
> +	if (!bz || (bz & (bz - 1)) != 0)

we have is_power_of_2()

> +		return -EINVAL;
> +
> +	if (memory_block_size_probed)
> +		return -EBUSY;
> +
> +	if (memory_block_advised_sz)
> +		memory_block_advised_sz = min(bz, memory_block_advised_sz);
> +	else
> +		memory_block_advised_sz = bz;
> +
> +	return 0;
> +}
> +
> +/*

should it be kernel-doc?

> + * memory_block_probe_max_size provides a suggested maximum memory block
> + * size value. After the first call, the value can never change.
> + *
> + * Returns: advised size in bytes, or 0 if never set.
> + */
> +size_t memory_block_probe_max_size(void)
> +{
> +	memory_block_size_probed = true;
> +	return memory_block_advised_sz;
> +}
> +
>  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..47c00d6e1165 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(size_t size)
> +{
> +	return -ENODEV;
> +}
> +static inline size_t memory_block_probe_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(size_t size);
> +size_t memory_block_probe_max_size(void);
>  #endif	/* CONFIG_MEMORY_HOTPLUG */
>  
>  /*
> -- 
> 2.43.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v3 1/3] memory: implement memory_block_advise/probe_max_size

[David Hildenbrand]

On 22.10.24 23:34, 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.
> 
> Suggested-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Gregory Price <gourry@gourry.net>
> ---
>   drivers/base/memory.c  | 43 ++++++++++++++++++++++++++++++++++++++++++
>   include/linux/memory.h | 10 ++++++++++
>   2 files changed, 53 insertions(+)
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 67858eeb92ed..a0fd9e1451aa 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -110,6 +110,49 @@ static void memory_block_release(struct device *dev)
>   	kfree(mem);
>   }
>   
> +/*


As Mike says, this documentation looks incomplete.

/**
  * memory_block_advise_max_size: suggest a maximum memory block size
  ...

> + * @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

Missing space after "size."

> + * identify the largest supported alignment for all sources.
> + *
> + * Use of this value is arch dependent, as is min/max block size.
> + *
> + * Returns: 0 on success
> + *	    -EINVAL if size is 0 or not pow2 aligned
> + *	    -EBUSY if value has already been probed
> + */
> +static size_t memory_block_advised_sz;
> +static bool memory_block_size_probed;
> +int memory_block_advise_max_size(size_t bz)
> +{
> +	if (!bz || (bz & (bz - 1)) != 0)
> +		return -EINVAL;
> +
> +	if (memory_block_size_probed)
> +		return -EBUSY;
> +
> +	if (memory_block_advised_sz)
> +		memory_block_advised_sz = min(bz, memory_block_advised_sz);
> +	else
> +		memory_block_advised_sz = bz;
> +
> +	return 0;
> +}
> +
> +/*
> + * memory_block_probe_max_size provides a suggested maximum memory block
> + * size value. After the first call, the value can never change.
> + *
> + * Returns: advised size in bytes, or 0 if never set.
> + */
> +size_t memory_block_probe_max_size(void)

Can we call that "memory_block_advised_max_size()" ?

> +{
> +	memory_block_size_probed = true;

Call this "memory_block_advised_size_queried" ?

> +	return memory_block_advised_sz;
> +}



-- 
Cheers,

David / dhildenb

[PATCH v3 2/3] x86: probe memory block size advisement value during mm init

[Gregory Price]

Systems with hotplug may provide an advisement value on what the
memblock size should be.  Probe this value when the rest of the
configuration values are considered.

The new heuristic is as follows

1) set_memory_block_size_order value if already set (cmdline param)
2) minimum block size if memory is less than large block limit
3) if no hotplug advice: Max block size if system is bare-metal,
   otherwise use end of memory alignment.
4) if hotplug advice: lesser of advice and end of memory alignment.

Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Gregory Price <gourry@gourry.net>
---
 arch/x86/mm/init_64.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index ff253648706f..93d669f467f7 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1452,13 +1452,17 @@ static unsigned long probe_memory_block_size(void)
 	}
 
 	/*
-	 * Use max block size to minimize overhead on bare metal, where
-	 * alignment for memory hotplug isn't a concern.
+	 * When hotplug alignment is not a concern, maximize blocksize
+	 * to minimize overhead. Otherwise, align to the lesser of advice
+	 * alignment and end of memory alignment.
 	 */
-	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
+	bz = memory_block_probe_max_size();
+	if (!bz) {
 		bz = MAX_BLOCK_SIZE;
-		goto done;
-	}
+		if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
+			goto done;
+	} else
+		bz = max(min(bz, MAX_BLOCK_SIZE), MIN_MEMORY_BLOCK_SIZE);
 
 	/* Find the largest allowed block size that aligns to memory end */
 	for (bz = MAX_BLOCK_SIZE; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {
-- 
2.43.0

Re: [PATCH v3 2/3] x86: probe memory block size advisement value during mm init

[David Hildenbrand]

On 22.10.24 23:34, Gregory Price wrote:
> Systems with hotplug may provide an advisement value on what the
> memblock size should be.  Probe this value when the rest of the
> configuration values are considered.
> 
> The new heuristic is as follows
> 
> 1) set_memory_block_size_order value if already set (cmdline param)
> 2) minimum block size if memory is less than large block limit
> 3) if no hotplug advice: Max block size if system is bare-metal,
>     otherwise use end of memory alignment.
> 4) if hotplug advice: lesser of advice and end of memory alignment.
> 
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Gregory Price <gourry@gourry.net>
> ---
>   arch/x86/mm/init_64.c | 14 +++++++++-----
>   1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index ff253648706f..93d669f467f7 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1452,13 +1452,17 @@ static unsigned long probe_memory_block_size(void)
>   	}
>   
>   	/*
> -	 * Use max block size to minimize overhead on bare metal, where
> -	 * alignment for memory hotplug isn't a concern.
> +	 * When hotplug alignment is not a concern, maximize blocksize
> +	 * to minimize overhead. Otherwise, align to the lesser of advice
> +	 * alignment and end of memory alignment.
>   	 */
> -	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
> +	bz = memory_block_probe_max_size();
> +	if (!bz) {
>   		bz = MAX_BLOCK_SIZE;
> -		goto done;
> -	}
> +		if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> +			goto done;
> +	} else
> +		bz = max(min(bz, MAX_BLOCK_SIZE), MIN_MEMORY_BLOCK_SIZE);
>   
>   	/* Find the largest allowed block size that aligns to memory end */
>   	for (bz = MAX_BLOCK_SIZE; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {


Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb

Re: [PATCH v3 2/3] x86: probe memory block size advisement value during mm init

[Gregory Price]

On Tue, Oct 29, 2024 at 01:40:38PM +0100, David Hildenbrand wrote:
> On 22.10.24 23:34, Gregory Price wrote:
> > Systems with hotplug may provide an advisement value on what the
> > memblock size should be.  Probe this value when the rest of the
> > configuration values are considered.
> > 
> > The new heuristic is as follows
> > 
> > 1) set_memory_block_size_order value if already set (cmdline param)
> > 2) minimum block size if memory is less than large block limit
> > 3) if no hotplug advice: Max block size if system is bare-metal,
> >     otherwise use end of memory alignment.
> > 4) if hotplug advice: lesser of advice and end of memory alignment.
> > 
> > Suggested-by: David Hildenbrand <david@redhat.com>
> > Signed-off-by: Gregory Price <gourry@gourry.net>
> > ---
> >   arch/x86/mm/init_64.c | 14 +++++++++-----
> >   1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> > index ff253648706f..93d669f467f7 100644
> > --- a/arch/x86/mm/init_64.c
> > +++ b/arch/x86/mm/init_64.c
> > @@ -1452,13 +1452,17 @@ static unsigned long probe_memory_block_size(void)
> >   	}
> >   	/*
> > -	 * Use max block size to minimize overhead on bare metal, where
> > -	 * alignment for memory hotplug isn't a concern.
> > +	 * When hotplug alignment is not a concern, maximize blocksize
> > +	 * to minimize overhead. Otherwise, align to the lesser of advice
> > +	 * alignment and end of memory alignment.
> >   	 */
> > -	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
> > +	bz = memory_block_probe_max_size();
> > +	if (!bz) {
> >   		bz = MAX_BLOCK_SIZE;
> > -		goto done;
> > -	}
> > +		if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > +			goto done;
> > +	} else
> > +		bz = max(min(bz, MAX_BLOCK_SIZE), MIN_MEMORY_BLOCK_SIZE);
> >   	/* Find the largest allowed block size that aligns to memory end */
> >   	for (bz = MAX_BLOCK_SIZE; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {
        ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 
> Acked-by: David Hildenbrand <david@redhat.com>

Will pick this up but wanted to point out the silly bug above.
This version completely ignores the advise lol.

Changing to below

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 93d669f467f7..01876629f21f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1465,7 +1465,7 @@ static unsigned long probe_memory_block_size(void)
                bz = max(min(bz, MAX_BLOCK_SIZE), MIN_MEMORY_BLOCK_SIZE);

        /* Find the largest allowed block size that aligns to memory end */
-       for (bz = MAX_BLOCK_SIZE; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {
+       for (; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {
                if (IS_ALIGNED(boot_mem_end, bz))
                        break;
        }

> 
> -- 
> Cheers,
> 
> David / dhildenb
> 

Re: [PATCH v3 2/3] x86: probe memory block size advisement value during mm init

[David Hildenbrand]

On 29.10.24 14:48, Gregory Price wrote:
> On Tue, Oct 29, 2024 at 01:40:38PM +0100, David Hildenbrand wrote:
>> On 22.10.24 23:34, Gregory Price wrote:
>>> Systems with hotplug may provide an advisement value on what the
>>> memblock size should be.  Probe this value when the rest of the
>>> configuration values are considered.
>>>
>>> The new heuristic is as follows
>>>
>>> 1) set_memory_block_size_order value if already set (cmdline param)
>>> 2) minimum block size if memory is less than large block limit
>>> 3) if no hotplug advice: Max block size if system is bare-metal,
>>>      otherwise use end of memory alignment.
>>> 4) if hotplug advice: lesser of advice and end of memory alignment.
>>>
>>> Suggested-by: David Hildenbrand <david@redhat.com>
>>> Signed-off-by: Gregory Price <gourry@gourry.net>
>>> ---
>>>    arch/x86/mm/init_64.c | 14 +++++++++-----
>>>    1 file changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>>> index ff253648706f..93d669f467f7 100644
>>> --- a/arch/x86/mm/init_64.c
>>> +++ b/arch/x86/mm/init_64.c
>>> @@ -1452,13 +1452,17 @@ static unsigned long probe_memory_block_size(void)
>>>    	}
>>>    	/*
>>> -	 * Use max block size to minimize overhead on bare metal, where
>>> -	 * alignment for memory hotplug isn't a concern.
>>> +	 * When hotplug alignment is not a concern, maximize blocksize
>>> +	 * to minimize overhead. Otherwise, align to the lesser of advice
>>> +	 * alignment and end of memory alignment.
>>>    	 */
>>> -	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
>>> +	bz = memory_block_probe_max_size();
>>> +	if (!bz) {
>>>    		bz = MAX_BLOCK_SIZE;
>>> -		goto done;
>>> -	}
>>> +		if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
>>> +			goto done;
>>> +	} else
>>> +		bz = max(min(bz, MAX_BLOCK_SIZE), MIN_MEMORY_BLOCK_SIZE);
>>>    	/* Find the largest allowed block size that aligns to memory end */
>>>    	for (bz = MAX_BLOCK_SIZE; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {
>          ^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>> Acked-by: David Hildenbrand <david@redhat.com>
> 
> Will pick this up but wanted to point out the silly bug above.
> This version completely ignores the advise lol.
> 
> Changing to below
> 
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 93d669f467f7..01876629f21f 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1465,7 +1465,7 @@ static unsigned long probe_memory_block_size(void)
>                  bz = max(min(bz, MAX_BLOCK_SIZE), MIN_MEMORY_BLOCK_SIZE);
> 
>          /* Find the largest allowed block size that aligns to memory end */
> -       for (bz = MAX_BLOCK_SIZE; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {
> +       for (; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {
>                  if (IS_ALIGNED(boot_mem_end, bz))
>                          break;

Heh, yes, I think I suggested that in my quick draft.

-- 
Cheers,

David / dhildenb

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

[Gregory Price]

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;
+
+	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)
-- 
2.43.0

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

[Mike Rapoport]

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
> 

-- 
Sincerely yours,
Mike.

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

[Gregory Price]

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.

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

[David Hildenbrand]

>   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.

-- 
Cheers,

David / dhildenb

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

[Gregory Price]

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

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

[Mike Rapoport]

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

-- 
Sincerely yours,
Mike.