arch/x86/mm/init_64.c | 15 ++++++++---- drivers/acpi/numa/srat.c | 12 ++++++++- drivers/base/memory.c | 53 ++++++++++++++++++++++++++++++++++++++++ include/linux/memory.h | 10 ++++++++ 4 files changed, 84 insertions(+), 6 deletions(-)
v8: nits and tag pickups
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 (i.e. not 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/query functions in driverse/base/memory.c to
report/query architecture agnostic hotplug block 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 query has already
occurred, but this is predicated on the notion that query actually
occurs (which presently only happens on the x86 arch). This is to
assist debugging future users. Otherwise, the advise() call has
been marked __init to help static discovery of bad call times.
Once query 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>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Gregory Price <gourry@gourry.net>
Tested-by: Fan Ni <fan.ni@samsung.com>
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 | 15 ++++++++----
drivers/acpi/numa/srat.c | 12 ++++++++-
drivers/base/memory.c | 53 ++++++++++++++++++++++++++++++++++++++++
include/linux/memory.h | 10 ++++++++
4 files changed, 84 insertions(+), 6 deletions(-)
--
2.48.1
On Mon, Jan 27, 2025 at 10:34:02AM -0500, Gregory Price wrote: > v8: nits and tag pickups > > 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 (i.e. not special purpose memory). I wonder if something like this could help us in improving the ridiculous situation of having 16MB memory-block size on powerpc. -- Oscar Salvador SUSE Labs
Oscar Salvador wrote: > On Mon, Jan 27, 2025 at 10:34:02AM -0500, Gregory Price wrote: > > v8: nits and tag pickups > > > > 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 (i.e. not special purpose memory). > > I wonder if something like this could help us in improving the > ridiculous situation of having 16MB memory-block size on powerpc. It's only ridiculous due to what it does to /sys/.../memory, right? If you permit me a bit of hand-waving, it would be lovely to deprecate /sys/.../memory in favor of a new (fd based?) ABI for memory-hotplug policy management and have something like a fuse "compatfs" mounted at /sys/.../memory/ for maintaining legacy compatibility for userspace that still depends on twiddling with individual blocks in sysfs.
On 01.04.25 20:53, Oscar Salvador wrote: > On Mon, Jan 27, 2025 at 10:34:02AM -0500, Gregory Price wrote: >> v8: nits and tag pickups >> >> 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 (i.e. not special purpose memory). > > I wonder if something like this could help us in improving the > ridiculous situation of having 16MB memory-block size on powerpc. They have this granularity because ... they want to add/remove memory in 16MiB on some powerpc dlpar machines :( probe_memory_block_size() can query the hypervisor on the actual hot(un)plug size. IIRC, QEMU sets it to 256 MiB. -- Cheers, David / dhildenb
On Tue, Apr 01, 2025 at 09:08:31PM +0200, David Hildenbrand wrote: > On 01.04.25 20:53, Oscar Salvador wrote: > > On Mon, Jan 27, 2025 at 10:34:02AM -0500, Gregory Price wrote: > > > v8: nits and tag pickups > > > > > > 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 (i.e. not special purpose memory). > > > > I wonder if something like this could help us in improving the > > ridiculous situation of having 16MB memory-block size on powerpc. > > They have this granularity because ... they want to add/remove memory in > 16MiB on some powerpc dlpar machines :( I'm not sure they do it today, there's a comment in near define of that 16M in arch/powerpc/mm/init_64.c: /* * Outside hotplug the kernel uses this value to map the kernel direct map * with radix. To be compatible with older kernels, let's keep this value * as 16M which is also SECTION_SIZE with SPARSEMEM. We can ideally map * things with 1GB size in the case where we don't support hotplug. */ and their SECTION_SIZE didn't change since 2005. Quite possible that they'll be fine with increasing their DEFAULT_MEMORY_BLOCK_SIZE. > probe_memory_block_size() can query the hypervisor on the actual hot(un)plug > size. IIRC, QEMU sets it to 256 MiB. > > -- > Cheers, > > David / dhildenb > -- Sincerely yours, Mike.
On 02.04.25 11:39, Mike Rapoport wrote: > On Tue, Apr 01, 2025 at 09:08:31PM +0200, David Hildenbrand wrote: >> On 01.04.25 20:53, Oscar Salvador wrote: >>> On Mon, Jan 27, 2025 at 10:34:02AM -0500, Gregory Price wrote: >>>> v8: nits and tag pickups >>>> >>>> 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 (i.e. not special purpose memory). >>> >>> I wonder if something like this could help us in improving the >>> ridiculous situation of having 16MB memory-block size on powerpc. >> >> They have this granularity because ... they want to add/remove memory in >> 16MiB on some powerpc dlpar machines :( > > I'm not sure they do it today, there's a comment in near define of that 16M > in arch/powerpc/mm/init_64.c: > > /* > * Outside hotplug the kernel uses this value to map the kernel direct map > * with radix. To be compatible with older kernels, let's keep this value > * as 16M which is also SECTION_SIZE with SPARSEMEM. We can ideally map > * things with 1GB size in the case where we don't support hotplug. > */ > > and their SECTION_SIZE didn't change since 2005. > Quite possible that they'll be fine with increasing their > DEFAULT_MEMORY_BLOCK_SIZE. At least modern PowerVM on Power10 seems to support LMBs of 128 MiB. "Based on this data, Power10 initially only supported LMB sizes of 128MB and 256MB." The default usually seems to be 256 MiB. In reality, the expectation is that the hypervisor will always communicate the LMB such that the memory block size will be set to that. Assuming we'd increase DEFAULT_MEMORY_BLOCK_SIZE to 128MiB, we might also be able to increase SECTION_SIZE to 128 MiB I assume. Not sure about older PowerVM / systems. [1] https://community.ibm.com/community/user/power/blogs/pete-heyrman1/2024/03/06/power10-lmb-sizes -- Cheers, David / dhildenb
On Mon, Jan 27, 2025 at 10:34:02AM -0500, Gregory Price wrote: > v8: nits and tag pickups > I apparently already cleaned up the remaining nits. So this has been stable. Just did a rebase on mm-unstable and it was clean, so this should pluck cleanly. Andrew, do you think this should go through mm or another subsystem? ~Gregory > 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 (i.e. not 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/query functions in driverse/base/memory.c to > report/query architecture agnostic hotplug block 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 query has already > occurred, but this is predicated on the notion that query actually > occurs (which presently only happens on the x86 arch). This is to > assist debugging future users. Otherwise, the advise() call has > been marked __init to help static discovery of bad call times. > > Once query 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> > Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> > Acked-by: David Hildenbrand <david@redhat.com> > Acked-by: Dan Williams <dan.j.williams@intel.com> > Acked-by: Dave Hansen <dave.hansen@linux.intel.com> > Signed-off-by: Gregory Price <gourry@gourry.net> > Tested-by: Fan Ni <fan.ni@samsung.com> > > 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 | 15 ++++++++---- > drivers/acpi/numa/srat.c | 12 ++++++++- > drivers/base/memory.c | 53 ++++++++++++++++++++++++++++++++++++++++ > include/linux/memory.h | 10 ++++++++ > 4 files changed, 84 insertions(+), 6 deletions(-) > > -- > 2.48.1 >
© 2016 - 2025 Red Hat, Inc.