All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Ira Weiny <ira.weiny@intel.com>,
	Michal Clapinski <mclapinski@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Jonathan Corbet <corbet@lwn.net>,
	nvdimm@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] libnvdimm/e820: Add a new parameter to configure many regions per e820 entry
Date: Tue, 27 May 2025 16:25:53 +0300	[thread overview]
Message-ID: <aDW9YRpTmI66gK_G@kernel.org> (raw)
In-Reply-To: <CA+CK2bD8t+s7gFGDCdqA8ZaoS3exM-_9N01mYY3OB4ryBGSCEQ@mail.gmail.com>

On Mon, Apr 21, 2025 at 10:55:25AM -0400, Pasha Tatashin wrote:
> On Sun, Apr 20, 2025 at 10:06 PM Ira Weiny <ira.weiny@intel.com> wrote:
> >
> > Michal Clapinski wrote:
> > > Currently, the user has to specify each memory region to be used with
> > > nvdimm via the memmap parameter. Due to the character limit of the
> > > command line, this makes it impossible to have a lot of pmem devices.
> > > This new parameter solves this issue by allowing users to divide
> > > one e820 entry into many nvdimm regions.
> > >
> > > This change is needed for the hypervisor live update. VMs' memory will
> > > be backed by those emulated pmem devices. To support various VM shapes
> > > I want to create devdax devices at 1GB granularity similar to hugetlb.
> >
> > Why is it not sufficient to create a region out of a single memmap range
> > and create multiple 1G dax devices within that single range?
> 
> This method implies using the ndctl tool to create regions and convert
> them to dax devices from userspace. This does not work for our use
> case. We must have these 1 GB regions available during boot because we
> do not want to lose memory for a devdax label. I.e., if fsdax is
> created during boot (i.e. default pmem format), it does not have a
> label. However, if it is created from userspace, we create a label
> with partition properties, UUID, etc. Here, we need to use kernel

Doesn't ndctl refuse to alter namespaces on "legacy" (i.e. memmap=)
regions?

> parameters to specify the properties of the pmem devices during boot
> so they can persist across reboots without losing any memory to
> labels.
> 
> Pasha

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2025-05-27 13:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17 14:25 [PATCH v2 1/1] libnvdimm/e820: Add a new parameter to configure many regions per e820 entry Michal Clapinski
2025-04-21  2:06 ` Ira Weiny
2025-04-21 14:55   ` Pasha Tatashin
2025-05-27 13:25     ` Mike Rapoport [this message]
2025-05-28 14:53       ` Pasha Tatashin
2025-04-21 23:20 ` Dan Williams
2025-04-22 13:10   ` Pasha Tatashin
2025-04-22 19:00     ` Dan Williams
2025-04-22 19:40       ` Dan Williams

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=aDW9YRpTmI66gK_G@kernel.org \
    --to=rppt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --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.