Hi Stanislav,
On 09/25/23 at 02:27pm, Stanislav Kinsburskii wrote:
> This patch introduces a memory allocator specifically tailored for
> persistent memory within the kernel. The allocator maintains
> kernel-specific states like DMA passthrough device states, IOMMU state, and
> more across kexec.
Can you give more details about how this persistent memory pool will be
utilized in a actual scenario? I mean, what problem have you met so that
you have to introduce persistent memory pool to solve it?
Thanks
Baoquan
>
> The current implementation provides a foundation for custom solutions that
> may be developed in the future. Although the design is kept concise and
> straightforward to encourage discussion and feedback, it remains fully
> functional.
>
> The persistent memory pool builds upon the continuous memory allocator
> (CMA) and ensures CMA state persistency across kexec by incorporating the
> CMA bitmap into the memory region instead of allocation it from kernel
> memory.
>
> Persistent memory pool metadata is passed across kexec by using Flattened
> Device Tree, which is added as another kexec segment for x86 architecture.
>
> Potential applications include:
>
> 1. Enabling various in-kernel entities to allocate persistent pages from
> a unified memory pool, obviating the need for reserving multiple
> regions.
>
> 2. For in-kernel components that need the allocation address to be
> retained on kernel kexec, this address can be exposed to user space
> and subsequently passed through the command line.
>
> 3. Distinct subsystems or drivers can set aside their region, allocating
> a segment for their persistent memory pool, suitable for uses such as
> file systems, key-value stores, and other applications.
>
> Notes:
>
> 1. The last patch of the series represents a use case for the feature.
> However, the patch won't compile and is for illustrative purposes only
> as the code being patched hasn't been merged yet.
>
> 2. The code being patched is currently under review by the community. The
> series is named "Introduce /dev/mshv drivers":
>
> https://lkml.org/lkml/2023/9/22/1117
>
>
> Changes since v1:
>
> 1. Persistent memory pool is now a wrapper on top of CMA instead of being a
> new allocator.
>
> 2. Persistent memory pool metadata doesn't belong to the pool anymore and
> is now passed via Flattened Device Tree instead over kexec to the new
> kernel.
>
> The following series implements...
>
> ---
>
> Stanislav Kinsburskii (7):
> kexec_file: Add fdt modification callback support
> x86: kexec: Transfer existing fdt to the new kernel
> x86: kexec: Enable fdt modification in callbacks
> pmpool: Introduce persistent memory pool
> pmpool: Update device tree on kexec
> pmpool: Restore state from device tree post-kexec
> Drivers: hv: Allocate persistent pages for root partition
>
>
> arch/x86/Kconfig | 16 +++
> arch/x86/kernel/kexec-bzimage64.c | 97 +++++++++++++++++
> drivers/hv/hv_common.c | 13 ++
> include/linux/kexec.h | 7 +
> include/linux/pmpool.h | 22 ++++
> kernel/kexec_file.c | 24 ++++
> mm/Kconfig | 9 ++
> mm/Makefile | 1
> mm/pmpool.c | 208 +++++++++++++++++++++++++++++++++++++
> 9 files changed, 394 insertions(+), 3 deletions(-)
> create mode 100644 include/linux/pmpool.h
> create mode 100644 mm/pmpool.c
>
>
> _______________________________________________
> kexec mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/kexec
>