From: Dan Williams <dan.j.williams@intel.com>
To: Rob Herring <robh@kernel.org>
Cc: Device Tree <devicetree@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH 6/6] doc/devicetree: NVDIMM region documentation
Date: Wed, 28 Mar 2018 10:25:28 -0700 [thread overview]
Message-ID: <CAPcyv4htpLN16d8JW+_pSy-ORwkQdVnv3guOS0FVmyy+ajvP=Q@mail.gmail.com> (raw)
In-Reply-To: <CAL_Jsq+jC2mAXbKh9c8dbLXZmWbD-sFemrk+8p-oGMkXqSMfnQ@mail.gmail.com>
On Wed, Mar 28, 2018 at 10:06 AM, Rob Herring <robh@kernel.org> wrote:
[..]
> >> Are DIMMs always going to be the only form factor for NV memory?
> >>
> >> And if you have multiple DIMMs, does each DT node correspond to a DIMM?
> >
> > A nvdimm-region might correspond to a single NVDIMM, a set of
> > interleaved NVDIMMs, or it might just be a chunk of normal memory that
> > you want treated as a NVDIMM for some reason. The last case is useful
> > for provisioning install media on servers since it allows you do
> > download a DVD image, turn it into an nvdimm-region, and kexec into
> > the installer which can use it as a root disk. That may seem a little
> > esoteric, but it's handy and we're using a full linux environment for
> > our boot loader so it's easy to make use of.
>
> I'm really just asking if we should drop the "dimm" name because it is
> not always a DIMM. Maybe pmem instead? I don't know, naming is
> hard(TM).
The Linux enabling uses the term "memory device". The Linux device
object name for memory devices is "nmem".
[..]
> > special since the OS needs to know where it can allocate early in boot
> > and I don't see non-volatile memory as being similarly significant.
> > Fundamentally an NVDIMM is just a memory mapped storage device so we
> > should be able to defer looking at them until later in boot.
>
> It's not clear if 'platform' is just an example or random name or what
> the node is required to be called. In the latter case, we should be
> much more specific because 'platform' could be anything. In the former
> case, then we have no way to find or validate the node because the
> name could be anything and there's no compatible property either.
>
> "region" is pretty generic too.
>
The term "nvdimm-region" has specific meaning to the libnvdimm
sub-system. It is a contiguous physical address range backed by one or
more memory devices, DIMMs, in an interleaved configuration
(interleave set).
One feature that is currently missing from libnvdimm is a management
interface to change an interleave configuration. To date, Linux only
reads a static region configuration published by platform firmware.
Linux can provide dynamic provisioning of namespaces out of those
regions, but interleave configuration has been left to vendor specific
tooling to date. It would be great to start incorporating generic
Linux support for that capability across platform firmware
implementations.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Device Tree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linuxppc-dev
<linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org"
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH 6/6] doc/devicetree: NVDIMM region documentation
Date: Wed, 28 Mar 2018 10:25:28 -0700 [thread overview]
Message-ID: <CAPcyv4htpLN16d8JW+_pSy-ORwkQdVnv3guOS0FVmyy+ajvP=Q@mail.gmail.com> (raw)
In-Reply-To: <CAL_Jsq+jC2mAXbKh9c8dbLXZmWbD-sFemrk+8p-oGMkXqSMfnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Mar 28, 2018 at 10:06 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
[..]
> >> Are DIMMs always going to be the only form factor for NV memory?
> >>
> >> And if you have multiple DIMMs, does each DT node correspond to a DIMM?
> >
> > A nvdimm-region might correspond to a single NVDIMM, a set of
> > interleaved NVDIMMs, or it might just be a chunk of normal memory that
> > you want treated as a NVDIMM for some reason. The last case is useful
> > for provisioning install media on servers since it allows you do
> > download a DVD image, turn it into an nvdimm-region, and kexec into
> > the installer which can use it as a root disk. That may seem a little
> > esoteric, but it's handy and we're using a full linux environment for
> > our boot loader so it's easy to make use of.
>
> I'm really just asking if we should drop the "dimm" name because it is
> not always a DIMM. Maybe pmem instead? I don't know, naming is
> hard(TM).
The Linux enabling uses the term "memory device". The Linux device
object name for memory devices is "nmem".
[..]
> > special since the OS needs to know where it can allocate early in boot
> > and I don't see non-volatile memory as being similarly significant.
> > Fundamentally an NVDIMM is just a memory mapped storage device so we
> > should be able to defer looking at them until later in boot.
>
> It's not clear if 'platform' is just an example or random name or what
> the node is required to be called. In the latter case, we should be
> much more specific because 'platform' could be anything. In the former
> case, then we have no way to find or validate the node because the
> name could be anything and there's no compatible property either.
>
> "region" is pretty generic too.
>
The term "nvdimm-region" has specific meaning to the libnvdimm
sub-system. It is a contiguous physical address range backed by one or
more memory devices, DIMMs, in an interleaved configuration
(interleave set).
One feature that is currently missing from libnvdimm is a management
interface to change an interleave configuration. To date, Linux only
reads a static region configuration published by platform firmware.
Linux can provide dynamic provisioning of namespaces out of those
regions, but interleave configuration has been left to vendor specific
tooling to date. It would be great to start incorporating generic
Linux support for that capability across platform firmware
implementations.
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Rob Herring <robh@kernel.org>
Cc: Oliver <oohall@gmail.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
Device Tree <devicetree@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 6/6] doc/devicetree: NVDIMM region documentation
Date: Wed, 28 Mar 2018 10:25:28 -0700 [thread overview]
Message-ID: <CAPcyv4htpLN16d8JW+_pSy-ORwkQdVnv3guOS0FVmyy+ajvP=Q@mail.gmail.com> (raw)
In-Reply-To: <CAL_Jsq+jC2mAXbKh9c8dbLXZmWbD-sFemrk+8p-oGMkXqSMfnQ@mail.gmail.com>
On Wed, Mar 28, 2018 at 10:06 AM, Rob Herring <robh@kernel.org> wrote:
[..]
> >> Are DIMMs always going to be the only form factor for NV memory?
> >>
> >> And if you have multiple DIMMs, does each DT node correspond to a DIMM?
> >
> > A nvdimm-region might correspond to a single NVDIMM, a set of
> > interleaved NVDIMMs, or it might just be a chunk of normal memory that
> > you want treated as a NVDIMM for some reason. The last case is useful
> > for provisioning install media on servers since it allows you do
> > download a DVD image, turn it into an nvdimm-region, and kexec into
> > the installer which can use it as a root disk. That may seem a little
> > esoteric, but it's handy and we're using a full linux environment for
> > our boot loader so it's easy to make use of.
>
> I'm really just asking if we should drop the "dimm" name because it is
> not always a DIMM. Maybe pmem instead? I don't know, naming is
> hard(TM).
The Linux enabling uses the term "memory device". The Linux device
object name for memory devices is "nmem".
[..]
> > special since the OS needs to know where it can allocate early in boot
> > and I don't see non-volatile memory as being similarly significant.
> > Fundamentally an NVDIMM is just a memory mapped storage device so we
> > should be able to defer looking at them until later in boot.
>
> It's not clear if 'platform' is just an example or random name or what
> the node is required to be called. In the latter case, we should be
> much more specific because 'platform' could be anything. In the former
> case, then we have no way to find or validate the node because the
> name could be anything and there's no compatible property either.
>
> "region" is pretty generic too.
>
The term "nvdimm-region" has specific meaning to the libnvdimm
sub-system. It is a contiguous physical address range backed by one or
more memory devices, DIMMs, in an interleaved configuration
(interleave set).
One feature that is currently missing from libnvdimm is a management
interface to change an interleave configuration. To date, Linux only
reads a static region configuration published by platform firmware.
Linux can provide dynamic provisioning of namespaces out of those
regions, but interleave configuration has been left to vendor specific
tooling to date. It would be great to start incorporating generic
Linux support for that capability across platform firmware
implementations.
next prev parent reply other threads:[~2018-03-28 17:18 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 8:12 [PATCH 1/6] libnvdimm: Add of_node to region and bus descriptors Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 8:12 ` [PATCH 2/6] libnvdimm: Add nd_region_destroy() Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 16:59 ` Dan Williams
2018-03-23 16:59 ` Dan Williams
2018-03-23 16:59 ` Dan Williams
2018-03-25 23:24 ` Balbir Singh
2018-03-25 23:24 ` Balbir Singh
2018-03-25 23:24 ` Balbir Singh
2018-03-23 8:12 ` [PATCH 3/6] libnvdimm: Add device-tree based driver Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 17:07 ` Dan Williams
2018-03-23 17:07 ` Dan Williams
2018-03-23 17:07 ` Dan Williams
2018-03-26 1:07 ` Oliver
2018-03-26 1:07 ` Oliver
2018-03-26 1:07 ` Oliver
2018-03-25 2:51 ` kbuild test robot
2018-03-25 2:51 ` kbuild test robot
2018-03-25 2:51 ` kbuild test robot
2018-03-25 4:27 ` kbuild test robot
2018-03-25 4:27 ` kbuild test robot
2018-03-25 4:27 ` kbuild test robot
2018-03-25 4:28 ` [RFC PATCH] libnvdimm: bus_desc can be static kbuild test robot
2018-03-25 4:28 ` kbuild test robot
2018-03-25 4:28 ` kbuild test robot
2018-03-26 4:05 ` [PATCH 3/6] libnvdimm: Add device-tree based driver Balbir Singh
2018-03-26 4:05 ` Balbir Singh
2018-03-26 4:05 ` Balbir Singh
2018-03-23 8:12 ` [PATCH 4/6] libnvdimm/of: Symlink platform and region devices Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 17:08 ` Dan Williams
2018-03-23 17:08 ` Dan Williams
2018-03-23 17:08 ` Dan Williams
2018-03-23 8:12 ` [PATCH 5/6] powerpc/powernv: Create platform devs for nvdimm buses Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 8:12 ` [PATCH 6/6] doc/devicetree: NVDIMM region documentation Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-23 8:12 ` Oliver O'Halloran
2018-03-26 22:24 ` Rob Herring
2018-03-26 22:24 ` Rob Herring
2018-03-26 22:24 ` Rob Herring
2018-03-27 14:53 ` Oliver
2018-03-27 14:53 ` Oliver
2018-03-27 14:53 ` Oliver
2018-03-28 17:06 ` Rob Herring
2018-03-28 17:06 ` Rob Herring
2018-03-28 17:06 ` Rob Herring
2018-03-28 17:25 ` Dan Williams [this message]
2018-03-28 17:25 ` Dan Williams
2018-03-28 17:25 ` Dan Williams
2018-03-29 3:10 ` Oliver
2018-03-29 3:10 ` Oliver
2018-03-29 3:10 ` Oliver
2018-03-25 23:16 ` [PATCH 1/6] libnvdimm: Add of_node to region and bus descriptors Balbir Singh
2018-03-25 23:16 ` Balbir Singh
2018-03-25 23:16 ` Balbir Singh
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='CAPcyv4htpLN16d8JW+_pSy-ORwkQdVnv3guOS0FVmyy+ajvP=Q@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=robh@kernel.org \
/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.