From: Dan Williams <dan.j.williams@intel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-nvdimm <linux-nvdimm@ml01.01.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Dave Chinner <david@fromorbit.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-block@vger.kernel.org, Jeff Moyer <jmoyer@redhat.com>,
Jan Kara <jack@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: [PATCH 0/7] "Device DAX" for persistent memory
Date: Mon, 9 May 2016 13:40:03 -0700 [thread overview]
Message-ID: <CAPcyv4gskZwMBMoW6pW=0U71kmxFMpC+QWaJQhFkFbdGac6EdA@mail.gmail.com> (raw)
In-Reply-To: <20160509125735.GA4476@infradead.org>
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/
prev parent reply other threads:[~2016-05-09 20:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-08 22:35 [PATCH 0/7] "Device DAX" for persistent memory Dan Williams
2016-05-08 22:35 ` [PATCH 1/7] libnvdimm: cleanup nvdimm_namespace_common_probe(), kill 'host' Dan Williams
2016-05-09 7:55 ` Johannes Thumshirn
2016-05-08 22:35 ` [PATCH 2/7] libnvdimm, dax: introduce device-dax infrastructure Dan Williams
2016-05-08 22:35 ` [PATCH 3/7] libnvdimm, dax: reserve space to store labels for device-dax Dan Williams
2016-05-08 22:35 ` [PATCH 4/7] libnvdimm, dax: record the specified alignment of a dax-device instance Dan Williams
2016-05-08 22:35 ` [PATCH 5/7] /dev/dax, pmem: direct access to persistent memory Dan Williams
2016-05-08 22:35 ` [PATCH 6/7] /dev/dax, core: file operations and dax-mmap Dan Williams
2016-05-08 22:35 ` [PATCH 7/7] Revert "block: enable dax for raw block devices" Dan Williams
2016-05-09 12:57 ` [PATCH 0/7] "Device DAX" for persistent memory Christoph Hellwig
2016-05-09 20:40 ` Dan Williams [this message]
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='CAPcyv4gskZwMBMoW6pW=0U71kmxFMpC+QWaJQhFkFbdGac6EdA@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.com \
--cc=jmoyer@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=ross.zwisler@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).