From: Gregory Price <gourry@gourry.net>
To: x86@kernel.org, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-mm@kvack.org
Cc: dan.j.williams@intel.com, ira.weiny@intel.com, david@redhat.com,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, rafael@kernel.org, lenb@kernel.org,
rppt@kernel.org, akpm@linux-foundation.org,
alison.schofield@intel.com, Jonathan.Cameron@huawei.com,
rrichter@amd.com, ytcoode@gmail.com, haibo1.xu@intel.com,
dave.jiang@intel.com
Subject: [PATCH v2 0/3] mm/memblock,x86,acpi: hotplug memory alignment advisement
Date: Wed, 16 Oct 2024 15:24:42 -0400 [thread overview]
Message-ID: <20241016192445.3118-1-gourry@gourry.net> (raw)
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 mm/memblock.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). This is to assist debugging
future users who may mistakenly call this after allocator or smp init.
Likewise, if probe() occurs more than once, we return -EBUSY to prevent
inconsistent values from being reported - i.e. this interaction should
happen exactly once, and all other behavior is an error / the probed
value should be acquired via memory_block_size_bytes() instead.
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):
mm/memblock: implement memblock_advise_size_order and probe functions
x86: probe memblock size advisement value during mm init
acpi,srat: reduce memory block size if CFMWS has a smaller alignment
arch/x86/mm/init_64.c | 16 +++++++++++++
drivers/acpi/numa/srat.c | 42 ++++++++++++++++++++++++++++++++++
include/linux/memblock.h | 2 ++
mm/memblock.c | 49 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 109 insertions(+)
--
2.43.0
next reply other threads:[~2024-10-16 19:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 19:24 Gregory Price [this message]
2024-10-16 19:24 ` [PATCH v2 1/3] mm/memblock: implement memblock_advise_size_order and probe functions Gregory Price
2024-10-20 8:57 ` Mike Rapoport
2024-10-21 14:39 ` Gregory Price
2024-10-16 19:24 ` [PATCH v2 2/3] x86: probe memblock size advisement value during mm init Gregory Price
2024-10-21 11:12 ` David Hildenbrand
2024-10-21 14:46 ` Gregory Price
2024-10-21 15:57 ` David Hildenbrand
2024-10-21 16:17 ` Gregory Price
2024-10-21 16:04 ` Gregory Price
2024-10-16 19:24 ` [PATCH v2 3/3] acpi,srat: reduce memory block size if CFMWS has a smaller alignment Gregory Price
2024-10-21 9:51 ` [PATCH v2 0/3] mm/memblock,x86,acpi: hotplug memory alignment advisement David Hildenbrand
2024-10-21 14:51 ` Gregory Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241016192445.3118-1-gourry@gourry.net \
--to=gourry@gourry.net \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=david@redhat.com \
--cc=haibo1.xu@intel.com \
--cc=hpa@zytor.com \
--cc=ira.weiny@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rppt@kernel.org \
--cc=rrichter@amd.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=ytcoode@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox