Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1396511 > unrolled thread

[PATCH 0/7] "Device DAX" for persistent memory

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/7] "Device DAX" for persistent memory Dan Williams <dan.j.williams@intel.com> - 2016-05-09 00:40 +0200
    [PATCH 4/7] libnvdimm,  dax: record the specified alignment of a dax-device instance Dan Williams <dan.j.williams@intel.com> - 2016-05-09 00:40 +0200
    Re: [PATCH 0/7] "Device DAX" for persistent memory Christoph Hellwig <hch@infradead.org> - 2016-05-09 15:00 +0200
      Re: [PATCH 0/7] "Device DAX" for persistent memory Dan Williams <dan.j.williams@intel.com> - 2016-05-09 22:50 +0200

#1396511 — [PATCH 0/7] "Device DAX" for persistent memory

Device DAX is the device-centric analogue of Filesystem DAX
(CONFIG_FS_DAX).  It allows memory ranges to be allocated and mapped
without need of an intervening file system or being bound to block
device semantics.  Device DAX is strict and predictable.  Specifically
this interface:

1/ Guarantees fault granularity with respect to a given page size (pte,
pmd, or pud) set at configuration time.

2/ Enforces deterministic behavior by being strict about what fault
scenarios are supported.

This first implementation, for persistent memory, is targeted at
applications like hypervisors and some databases that only need an
allocate + map mechanism from the kernel.  Later this mechanism can be
used to enable direct access to other performance/feature differentiated
memory ranges.

This series is built on "[PATCH 00/13] prep for device-dax, untangle
pfn-device setup" [1], posted at the end of March.

A libnvdimm pmem namespace can be switched from its default /dev/pmemX
(block device) interface to /dev/daxX.Y with the ndctl utility:

    ndctl create-namespace -m dax -e namespace0.0 -f

This implementation passes a basic setup, map, fault, and shutdown
sequence.

[1]: https://lists.01.org/pipermail/linux-nvdimm/2016-March/005086.html

---

Dan Williams (7):
      libnvdimm: cleanup nvdimm_namespace_common_probe(), kill 'host'
      libnvdimm, dax: introduce device-dax infrastructure
      libnvdimm, dax: reserve space to store labels for device-dax
      libnvdimm, dax: record the specified alignment of a dax-device instance
      /dev/dax, pmem: direct access to persistent memory
      /dev/dax, core: file operations and dax-mmap
      Revert "block: enable dax for raw block devices"


 block/ioctl.c                       |   32 --
 drivers/Kconfig                     |    2 
 drivers/Makefile                    |    1 
 drivers/dax/Kconfig                 |   25 ++
 drivers/dax/Makefile                |    4 
 drivers/dax/dax.c                   |  543 +++++++++++++++++++++++++++++++++++
 drivers/dax/dax.h                   |   24 ++
 drivers/dax/pmem.c                  |  168 +++++++++++
 drivers/nvdimm/Kconfig              |   13 +
 drivers/nvdimm/Makefile             |    1 
 drivers/nvdimm/bus.c                |    4 
 drivers/nvdimm/claim.c              |    2 
 drivers/nvdimm/dax_devs.c           |   99 ++++++
 drivers/nvdimm/namespace_devs.c     |   38 ++
 drivers/nvdimm/nd-core.h            |    1 
 drivers/nvdimm/nd.h                 |   25 ++
 drivers/nvdimm/pfn.h                |    4 
 drivers/nvdimm/pfn_devs.c           |  116 +++++--
 drivers/nvdimm/region.c             |    2 
 drivers/nvdimm/region_devs.c        |   29 ++
 fs/block_dev.c                      |   96 ++----
 include/linux/fs.h                  |    8 -
 include/uapi/linux/fs.h             |    1 
 include/uapi/linux/ndctl.h          |    2 
 mm/huge_memory.c                    |    1 
 mm/hugetlb.c                        |    1 
 tools/testing/nvdimm/Kbuild         |   10 +
 tools/testing/nvdimm/config_check.c |    2 
 28 files changed, 1094 insertions(+), 160 deletions(-)
 create mode 100644 drivers/dax/Kconfig
 create mode 100644 drivers/dax/Makefile
 create mode 100644 drivers/dax/dax.c
 create mode 100644 drivers/dax/dax.h
 create mode 100644 drivers/dax/pmem.c
 create mode 100644 drivers/nvdimm/dax_devs.c

[toc] | [next] | [standalone]

#1396512 — [PATCH 4/7] libnvdimm, dax: record the specified alignment of a dax-device instance

We want to use the alignment as the allocation and mapping unit.
Previously this information was only useful for establishing the data
offset, but now it is important to remember the granularity for the
later use.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 drivers/nvdimm/pfn.h      |    4 +++-
 drivers/nvdimm/pfn_devs.c |    8 ++++++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/nvdimm/pfn.h b/drivers/nvdimm/pfn.h
index 8e343a3ca873..9d2704c83fa7 100644
--- a/drivers/nvdimm/pfn.h
+++ b/drivers/nvdimm/pfn.h
@@ -33,7 +33,9 @@ struct nd_pfn_sb {
 	/* minor-version-1 additions for section alignment */
 	__le32 start_pad;
 	__le32 end_trunc;
-	u8 padding[4004];
+	/* minor-version-2 record the base alignment of the mapping */
+	__le32 align;
+	u8 padding[4000];
 	__le64 checksum;
 };
 
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index ca396c8f2cd5..58740d7ce81b 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -394,6 +394,9 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn)
 		pfn_sb->end_trunc = 0;
 	}
 
+	if (__le16_to_cpu(pfn_sb->version_minor) < 2)
+		pfn_sb->align = 0;
+
 	switch (le32_to_cpu(pfn_sb->mode)) {
 	case PFN_MODE_RAM:
 	case PFN_MODE_PMEM:
@@ -433,7 +436,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn)
 		return -EBUSY;
 	}
 
-	nd_pfn->align = 1UL << ilog2(offset);
+	nd_pfn->align = le32_to_cpu(pfn_sb->align);
 	if (!is_power_of_2(offset) || offset < PAGE_SIZE) {
 		dev_err(&nd_pfn->dev, "bad offset: %#llx dax disabled\n",
 				offset);
@@ -629,9 +632,10 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
 	memcpy(pfn_sb->uuid, nd_pfn->uuid, 16);
 	memcpy(pfn_sb->parent_uuid, nd_dev_to_uuid(&ndns->dev), 16);
 	pfn_sb->version_major = cpu_to_le16(1);
-	pfn_sb->version_minor = cpu_to_le16(1);
+	pfn_sb->version_minor = cpu_to_le16(2);
 	pfn_sb->start_pad = cpu_to_le32(start_pad);
 	pfn_sb->end_trunc = cpu_to_le32(end_trunc);
+	pfn_sb->align = cpu_to_le32(nd_pfn->align);
 	checksum = nd_sb_checksum((struct nd_gen_sb *) pfn_sb);
 	pfn_sb->checksum = cpu_to_le64(checksum);
 

[toc] | [prev] | [next] | [standalone]

#1397026

On Sun, May 08, 2016 at 03:35:10PM -0700, Dan Williams wrote:
> Device DAX is the device-centric analogue of Filesystem DAX
> (CONFIG_FS_DAX).  It allows memory ranges to be allocated and mapped
> without need of an intervening file system or being bound to block
> device semantics.  Device DAX is strict and predictable.  Specifically
> this interface:

Can you explain the "why" a little more?

And please, if you decide to Cc me on some of the patches do it for the
whole series or none of it, but never just for some patches as that make
the cc pretty pointless.

[toc] | [prev] | [next] | [standalone]

#1397376

On Mon, May 9, 2016 at 5:57 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Sun, May 08, 2016 at 03:35:10PM -0700, Dan Williams wrote:
>> Device DAX is the device-centric analogue of Filesystem DAX
>> (CONFIG_FS_DAX).  It allows memory ranges to be allocated and mapped
>> without need of an intervening file system or being bound to block
>> device semantics.  Device DAX is strict and predictable.  Specifically
>> this interface:
>
> Can you explain the "why" a little more?

1/ As I mentioned at LSF [1] we're starting to see platforms with
performance and feature differentiated memory ranges.  Environments
like high-performance-computing and usages like in-memory databases
want 100% exclusive allocation of a memory range with zero conflicting
kernel/metadata allocations.  For dedicated applications of high
bandwidth or low latency memory device-DAX provides a predictable
direct map mechanism.

Note that this is only for the small number of "crazy" applications
that are willing to re-write to get every bit of performance.  For
everyone else we, Dave Hansen and I, are looking to add a mechanism to
hot-plug device-DAX ranges into the mm to get general memory
management services (oversubscribe / migration, etc) with the
understanding that it may sacrifice some predictability.

2/ For persistent memory there are similar applications that are
willing to re-write to take full advantage of byte-addressable
persistence.  This mechanism satisfies those usages that only need a
pre-allocated file to mmap.

3/ It answers Dave Chinner's call to start thinking about pmem-native
solutions.  Device DAX specifically avoids block-device and file
system conflicts.

> And please, if you decide to Cc me on some of the patches do it for the
> whole series or none of it, but never just for some patches as that make
> the cc pretty pointless.

Sorry, you've told me this before.  I'll update my scripts to
auto-include you on the whole series if you ever appear in the cc of
any patch in the set.

[1]: https://lwn.net/Articles/685107/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web