From: Mike Rapoport <rppt@kernel.org>
To: dan.j.williams@intel.com
Cc: "Michał Cłapiński" <mclapinski@google.com>,
"Ira Weiny" <ira.weiny@intel.com>,
"Dave Jiang" <dave.jiang@intel.com>,
"Vishal Verma" <vishal.l.verma@intel.com>,
jane.chu@oracle.com, "Pasha Tatashin" <pasha.tatashin@soleen.com>,
"Tyler Hicks" <code@tyhicks.com>,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev
Subject: Re: [PATCH 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices
Date: Tue, 30 Sep 2025 12:15:15 +0200 [thread overview]
Message-ID: <aNuts7yMTJdtmDXZ@kernel.org> (raw)
In-Reply-To: <68d6df3f410de_1052010059@dwillia2-mobl4.notmuch>
On Fri, Sep 26, 2025 at 11:45:19AM -0700, dan.j.williams@intel.com wrote:
> Michał Cłapiński wrote:
> [..]
> > > As Mike says you would lose 128K at the end, but that indeed becomes
> > > losing that 1GB given alignment constraints.
> > >
> > > However, I think that could be solved by just separately vmalloc'ing the
> > > label space for this. Then instead of kernel parameters to sub-divide a
> > > region, you just have an initramfs script to do the same.
> > >
> > > Does that meet your needs?
> >
> > Sorry, I'm having trouble imagining this.
> > If I wanted 500 1GB chunks, I would request a region of 500GB+space
> > for the label? Or is that a label and info-blocks?
>
> You would specify an memmap= range of 500GB+128K*.
>
> Force attach that range to Mike's RAMDAX driver.
>
> [ modprobe -r nd_e820, don't build nd_820, or modprobe policy blocks nd_e820 ]
> echo ramdax > /sys/bus/platform/devices/e820_pmem/driver_override
> echo e820_pmem > /sys/bus/platform/drivers/ramdax
>
> * forget what I said about vmalloc() previously, not needed
>
> > Then on each boot the kernel would check if there is an actual
> > label/info-blocks in that space and if yes, it would recreate my
> > devices (including the fsdax/devdax type)?
>
> Right, if that range is persistent the kernel would automatically parse
> the label space each boot and divide up the 500GB region space into
> namespaces.
>
> 128K of label spaces gives you 509 potential namespaces.
I was also thinking that the label area can be put either in the end or in
the beginning of the memmap= range, so that if you specify memmap=<1G
aligned address - 128K> the actual space will be 1G aligned.
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-09-30 10:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 8:04 [PATCH 0/1] nvdimm: allow exposing RAM as libnvdimm DIMMs Mike Rapoport
2025-08-26 8:04 ` [PATCH 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices Mike Rapoport
2025-08-29 0:47 ` Ira Weiny
2025-08-29 7:57 ` Mike Rapoport
2025-09-01 16:01 ` Michał Cłapiński
2025-09-02 15:35 ` Mike Rapoport
2025-09-24 1:16 ` dan.j.williams
2025-09-26 12:47 ` Michał Cłapiński
2025-09-26 18:45 ` dan.j.williams
2025-09-30 10:15 ` Mike Rapoport [this message]
2025-10-01 14:14 ` Michał Cłapiński
2025-10-01 22:28 ` dan.j.williams
2025-12-09 20:10 ` Michał Cłapiński
2025-12-17 3:14 ` dan.j.williams
2025-12-29 16:39 ` Michał Cłapiński
2026-01-12 23:36 ` Ira Weiny
2026-01-13 12:39 ` Michał Cłapiński
2026-01-14 2:34 ` dan.j.williams
2025-09-24 1:08 ` dan.j.williams
2025-09-30 10:11 ` Mike Rapoport
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=aNuts7yMTJdtmDXZ@kernel.org \
--to=rppt@kernel.org \
--cc=code@tyhicks.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=jane.chu@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mclapinski@google.com \
--cc=nvdimm@lists.linux.dev \
--cc=pasha.tatashin@soleen.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.