From: Jeff Moyer <jmoyer@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH] dax: adding fsync/msync support for device DAX
Date: Wed, 11 Apr 2018 13:27:53 -0400 [thread overview]
Message-ID: <x498t9tps9y.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <CAPcyv4guech76UWc7xo+SAzKOv8dT83HTUoUPVUCx5Kjuxy5Vg@mail.gmail.com> (Dan Williams's message of "Wed, 11 Apr 2018 09:27:22 -0700")
Dan Williams <dan.j.williams@intel.com> writes:
> On Wed, Apr 11, 2018 at 9:06 AM, Jeff Moyer <jmoyer@redhat.com> wrote:
>> Christoph Hellwig <hch@infradead.org> writes:
>>
>>> On Fri, Apr 06, 2018 at 03:41:39PM -0700, Dan Williams wrote:
>>>> Yes, but the trust interface definition is what is missing, especially
>>>> when we consider memmap=ss!nn and qemu-kvm. For example do we turn off
>>>> DAX and/or MAP_SYNC on all platforms that don't provide a positive "I
>>>> have ADR" indication (ACPI 6.2 Section 5.2.25.9 NFIT Platform
>>>> Capabilities Structure)?
>>>
>>> Sounds like a default.
>>
>> Which do you turn off? DAX or MAP_SYNC (or both)?
>
> Only MAP_SYNC I would say, because then userspace can't opt out of
> fsync/msync and it gives us a chance to "Do The Right Thing (TM)" with
> respect to WPQ flush.
That works for me.
>> Systems that support ACPI versions earlier than 6.2 could provide
>> flush hint addresses. In that case, we could assume no ADR, and turn
>> off MAP_SYNC, but still allow DAX. Note that I'm not aware of any
>> hardware that actually falls into this category.
>>
>> Platforms prior to 6.2 that don't support flush hints are currently
>> assumed to implement ADR. This proposal would change that default.
>>
>>>> Require opt-in when the user has trust in the hardware config that
>>>> the kernel can't verify?
>>>
>>> And that sounds like a good config nob ontop of that default.
>>
>> Well, we could also make a white-list for known good platforms. I
>> assume HPE's systems would be on that list. Otherwise we'd have to cook
>> up udev rules, I guess?
>
> udev rules sound good. We can distribute them in the ndctl package. I
> think I would handle this by making
> /sys/bus/nd/devices/regionX/persistence_domain writable to opt-in to a
> user specified persistence_domain. If the persistence_domain attribute
> file is not writable then you know you're on a kernel that blindly
> trusts all pmem descriptions as MAP_SYNC capable.
>
>> Dan, is this something you're working on now?
>
> No, it's behind finalizing dax-dma-vs-truncate and memcpy_mcsafe for
> user copies in my queue...
OK, I'll take a stab at it.
Thanks,
Jeff
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
prev parent reply other threads:[~2018-04-11 17:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-04 22:01 [PATCH] dax: adding fsync/msync support for device DAX Dave Jiang
2018-04-05 0:03 ` Dan Williams
2018-04-05 7:23 ` Christoph Hellwig
2018-04-05 7:56 ` Dan Williams
2018-04-05 8:01 ` Christoph Hellwig
2018-04-05 14:59 ` Jeff Moyer
2018-04-05 15:10 ` Christoph Hellwig
2018-04-05 22:17 ` Dan Williams
2018-04-06 7:03 ` Christoph Hellwig
2018-04-06 22:41 ` Dan Williams
2018-04-09 9:32 ` Christoph Hellwig
2018-04-11 16:06 ` Jeff Moyer
2018-04-11 16:27 ` Dan Williams
2018-04-11 17:27 ` Jeff Moyer [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=x498t9tps9y.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=linux-nvdimm@lists.01.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 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).