From: Randy Dunlap <rdunlap@infradead.org>
To: Gregory Price <gourry@gourry.net>, linux-cxl@vger.kernel.org
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, dave@stgolabs.net,
jonathan.cameron@huawei.com, dave.jiang@intel.com,
alison.schofield@intel.com, vishal.l.verma@intel.com,
ira.weiny@intel.com, dan.j.williams@intel.com, corbet@lwn.net
Subject: Re: [RFC PATCH v2 11/18] cxl: docs/linux/memory-hotplug
Date: Sat, 10 May 2025 19:22:22 -0700 [thread overview]
Message-ID: <7cfd6cb4-78fd-4db4-84db-d093aaeacb6d@infradead.org> (raw)
In-Reply-To: <20250430181048.1197475-12-gourry@gourry.net>
On 4/30/25 11:10 AM, Gregory Price wrote:
> Add documentation on how the CXL driver surfaces memory through the
> DAX driver and memory-hotplug.
>
> Signed-off-by: Gregory Price <gourry@gourry.net>
> ---
> Documentation/driver-api/cxl/index.rst | 1 +
> .../driver-api/cxl/linux/memory-hotplug.rst | 78 +++++++++++++++++++
> 2 files changed, 79 insertions(+)
> create mode 100644 Documentation/driver-api/cxl/linux/memory-hotplug.rst
>
> diff --git a/Documentation/driver-api/cxl/linux/memory-hotplug.rst b/Documentation/driver-api/cxl/linux/memory-hotplug.rst
> new file mode 100644
> index 000000000000..a757e0e4487e
> --- /dev/null
> +++ b/Documentation/driver-api/cxl/linux/memory-hotplug.rst
> @@ -0,0 +1,78 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==============
> +Memory Hotplug
> +==============
> +The final phase of surfacing CXL memory to the kernel page allocator is for
> +the `DAX` driver to surface a `Driver Managed` memory region via the
> +memory-hotplug component.
> +
> +There are four major configurations to consider
Add ending ':' ?
> +
> +1) Default Online Behavior (on/off and zone)
> +2) Hotplug Memory Block size
> +3) Memory Map Resource location
> +4) Driver-Managed Memory Designation
> +
> +Default Online Behavior
> +=======================
> +The default-online behavior of hotplug memory is dictated by the following,
> +in order of precedence:
> +
> +- :code:`CONFIG_MHP_DEFAULT_ONLINE_TYPE` Build Configuration
> +- :code:`memhp_default_state` Boot parameters
parameter
> +- :code:`/sys/devices/system/memory/auto_online_blocks` value
> +
> +These dictate whether hotplugged memory blocks arrive in one of three states:
> +
> +1) Offline
> +2) Online in :code:`ZONE_NORMAL`
> +3) Online in :code:`ZONE_MOVABLE`
> +
> +:code:`ZONE_NORMAL` implies this capacity may be used for almost any allocation,
> +while :code:`ZONE_MOVABLE` implies this capacity should only be used for
> +migratable allocations.
> +
> +:code:`ZONE_MOVABLE` attempts to retain the hotplug-ability of a memory block
> +so that it the entire region may be hot-unplugged at a later time. Any capacity
> +onlined into :code:`ZONE_NORMAL` should be considered permanently attached to
> +the page allocator.
> +
> +Hotplug Memory Block Size
> +=========================
> +By default, on most architectures, the Hotplug Memory Block Size is either
> +128MB or 256MB. On x86, the block size increases up to 2GB as total memory
> +capacity exceeds 64GB. As of v6.15, Linux does not take into account the
> +size and alignment of the ACPI CEDT CFMWS regions (see Early Boot docs) when
> +deciding the Hotplug Memory Block Size.
> +
> +Memory Map
> +==========
> +The location of :code:`struct folio` allocations to represent the hotplugged
> +memory capacity are dicated by the following system settings:
dictated
> +
> +- :code:`/sys_module/memory_hotplug/parameters/memmap_on_memory`
> +- :code:`/sys/bus/dax/devices/daxN.Y/memmap_on_memory`
> +
> +If both of these parameters are set to true, :code:`struct folio` for this
> +capacity will be carved out of the memory block being onlined. This has
> +performance implications if the memory is particularly high-latency and
> +its :code:`struct folio` becomes hotly contended.
> +
> +If either parameter is set to false, :code:`struct folio` for this capacity
> +will be allocated from the local node of the processor running the hotplug
> +procedure. This capacity will be allocated from :code:`ZONE_NORMAL` on
> +that node, as it is a :code:`GFP_KERNEL` allocation.
> +
> +Systems with extremely large amounts of :code:`ZONE_MOVABLE` memory (e.g.
> +CXL memory pools) must ensure that there is sufficient local
> +:code:`ZONE_NORMAL` capacity to host the memory map for the hotplugged capacity.
> +
> +Driver Managed Memory
> +=====================
> +The DAX driver surfaces this memory to memory-hotplug as "Driver Managed". This
> +is not a configurable setting, but it's important to not that driver managed
note
> +memory is explicitly excluded from use during kexec. This is required to ensure
> +any reset or out-of-band operations that the CXL device may be subject to during
> +a functional system-reboot (such as a reset-on-probe) will not cause portions of
> +the kexec kernel to be overwritten.
--
~Randy
next prev parent reply other threads:[~2025-05-11 2:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 18:10 [RFC PATCH v2 00/18] CXL Boot to Bash Documentation Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 01/18] cxl: update documentation structure in prep for new docs Gregory Price
2025-05-11 7:34 ` Bagas Sanjaya
2025-04-30 18:10 ` [RFC PATCH v2 02/18] cxl: docs/devices - device reference and uefi placeholder Gregory Price
2025-05-11 1:57 ` Randy Dunlap
2025-04-30 18:10 ` [RFC PATCH v2 03/18] cxl: docs/platform/bios-and-efi documentation Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 04/18] cxl: docs/platform/acpi reference documentation Gregory Price
2025-05-11 2:02 ` Randy Dunlap
2025-04-30 18:10 ` [RFC PATCH v2 05/18] cxl: docs/platform/example-configs documentation Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 06/18] cxl: docs/linux - overview Gregory Price
2025-05-11 2:06 ` Randy Dunlap
2025-04-30 18:10 ` [RFC PATCH v2 07/18] cxl: docs/linux - early boot configuration Gregory Price
2025-05-11 2:11 ` Randy Dunlap
2025-04-30 18:10 ` [RFC PATCH v2 08/18] cxl: docs/linux - add cxl-driver theory of operation Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 09/18] cxl: docs/linux/cxl-driver - add example configurations Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 10/18] cxl: docs/linux/dax-driver documentation Gregory Price
2025-05-11 2:18 ` Randy Dunlap
2025-05-12 14:31 ` Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 11/18] cxl: docs/linux/memory-hotplug Gregory Price
2025-05-11 2:22 ` Randy Dunlap [this message]
2025-04-30 18:10 ` [RFC PATCH v2 12/18] cxl: docs/allocation/dax Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 13/18] cxl: docs/allocation/page-allocator Gregory Price
2025-05-11 2:28 ` Randy Dunlap
2025-04-30 18:10 ` [RFC PATCH v2 14/18] cxl: docs/allocation/reclaim Gregory Price
2025-05-11 2:31 ` Randy Dunlap
2025-04-30 18:10 ` [RFC PATCH v2 15/18] cxl: docs/allocation/hugepages Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 16/18] cxl: docs/allocation/tiering Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 17/18] cxl: docs/use-cases Gregory Price
2025-04-30 18:10 ` [RFC PATCH v2 18/18] cxl: docs - add self-referencing cross-links Gregory Price
2025-05-11 2:54 ` Randy Dunlap
2025-05-11 9:14 ` Bagas Sanjaya
2025-04-30 23:15 ` [PATCH FIXUP] cxl: docs - fixup cedt.rst reference in access-coordinates 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=7cfd6cb4-78fd-4db4-84db-d093aaeacb6d@infradead.org \
--to=rdunlap@infradead.org \
--cc=alison.schofield@intel.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=gourry@gourry.net \
--cc=ira.weiny@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=kernel-team@meta.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vishal.l.verma@intel.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