Hi Ira,
On Thu, Aug 28, 2025 at 07:47:31PM -0500, Ira Weiny wrote:
> + Michal
>
> Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <r...@kernel.org>
> >
> > There are use cases, for example virtual machine hosts, that create
> > "persistent" memory regions using memmap= option on x86 or dummy
> > pmem-region device tree nodes on DT based systems.
> >
> > Both these options are inflexible because they create static regions and
> > the layout of the "persistent" memory cannot be adjusted without reboot
> > and sometimes they even require firmware update.
> >
> > Add a ramdax driver that allows creation of DIMM devices on top of
> > E820_TYPE_PRAM regions and devicetree pmem-region nodes.
>
> While I recognize this driver and the e820 driver are mutually
> exclusive[1][2]. I do wonder if the use cases are the same?
They are mutually exclusive in the sense that they cannot be loaded
together so I had this in Kconfig in RFC posting
config RAMDAX
tristate "Support persistent memory interfaces on RAM carveouts"
depends on OF || (X86 && X86_PMEM_LEGACY=n)
(somehow my rebase lost Makefile and Kconfig changes :( )
As Pasha said in the other thread [1] the use-cases are different. My goal
is to achieve flexibility in managing carved out "PMEM" regions and
Michal's patches aim to optimize boot time by autoconfiguring multiple PMEM
regions in the kernel without upcalls to ndctl.
> From a high level I don't like the idea of adding kernel parameters. So
> if this could solve Michal's problem I'm inclined to go this direction.
I think it could help with optimizing the reboot times. On the first boot
the PMEM is partitioned using ndctl and then the partitioning remains there
so that on subsequent reboots kernel recreates dax devices without upcalls
to userspace.
[1]
https://lore.kernel.org/all/ca+ck2bapjr00j3efztf7wgvgxuqmmotqjc8xo70bgyquskt...@mail.gmail.com/
--
Sincerely yours,
Mike.
