From: Dan Williams <dan.j.williams@intel.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-nvdimm@lists.01.org, Dave Chinner <david@fromorbit.com>,
linux-xfs <linux-xfs@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 2 2/2] xfs: fix rt_dev usage for DAX
Date: Tue, 6 Feb 2018 16:19:12 -0800 [thread overview]
Message-ID: <CAPcyv4jQ+ATdVUdF32+uZwcnTZCQnUSMD1fLg14JrT870jaB7g@mail.gmail.com> (raw)
In-Reply-To: <20180206231915.GA26233@magnolia>
On Tue, Feb 6, 2018 at 3:19 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote:
> On Tue, Feb 06, 2018 at 03:32:00PM -0700, Dave Jiang wrote:
[..]
> The last time I paid much attention to DAX was the thread "re-enable XFS
> per-inode DAX"[1] last September. Motivating me to merge anything else
> into DAX involves convincing me that we (mm, fs, dax developers) have
> some kind of agreement about what we want the user-visible interfaces to
> DAX to look like. Namely:
>
> 0. On what level do we allow users / administrators to control usage of
> the dax paths? Can the hardware convey enough detail to the kernel that
> the kernel can make a reasonable decision on its own whether buffered or
> dax io make more sense? If so, can we please just have that? If not,
> why?
>
> 1. If we want to let users override whatever decision the kernel makes,
> how should we do this? One mount option that applies to everything,
> like ext4? Inheritable inode flags, like xfs? Do we have one to force
> it on even if the kernel doesn't want to? Do we have another to force
> it off even if the kernel wants to? Do we even want to go down this
> path? Can we get away with making the answer to Q0 "yes" and then see
> if anyone actually complains about not having fine-grained control?
I think we will always have folks that want to force it on, i.e. the
MAP_SYNC user crowd. However, I think we might have some people what
will complain if they can't force it off. For example, I'm in the
process of killing off support for passing filesystem-dax mappings
through to guests because VFIO has the same "pin pages / fs-blocks
forever" problem as RDMA. Passing page cache through to a guest works
fine and it would be a shame if that silently stopped working in the
future. Given the page pinning constraint I'm not sure we can ever
support dynamically enabling DAX behind the user's back, at least not
until we kill off any "pin pages / fs-blocks forever" users, or
otherwise convert them to take a lease.
_______________________________________________
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: "Darrick J. Wong" <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>,
linux-xfs <linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-ext4 <linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 2 2/2] xfs: fix rt_dev usage for DAX
Date: Tue, 6 Feb 2018 16:19:12 -0800 [thread overview]
Message-ID: <CAPcyv4jQ+ATdVUdF32+uZwcnTZCQnUSMD1fLg14JrT870jaB7g@mail.gmail.com> (raw)
In-Reply-To: <20180206231915.GA26233@magnolia>
On Tue, Feb 6, 2018 at 3:19 PM, Darrick J. Wong <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, Feb 06, 2018 at 03:32:00PM -0700, Dave Jiang wrote:
[..]
> The last time I paid much attention to DAX was the thread "re-enable XFS
> per-inode DAX"[1] last September. Motivating me to merge anything else
> into DAX involves convincing me that we (mm, fs, dax developers) have
> some kind of agreement about what we want the user-visible interfaces to
> DAX to look like. Namely:
>
> 0. On what level do we allow users / administrators to control usage of
> the dax paths? Can the hardware convey enough detail to the kernel that
> the kernel can make a reasonable decision on its own whether buffered or
> dax io make more sense? If so, can we please just have that? If not,
> why?
>
> 1. If we want to let users override whatever decision the kernel makes,
> how should we do this? One mount option that applies to everything,
> like ext4? Inheritable inode flags, like xfs? Do we have one to force
> it on even if the kernel doesn't want to? Do we have another to force
> it off even if the kernel wants to? Do we even want to go down this
> path? Can we get away with making the answer to Q0 "yes" and then see
> if anyone actually complains about not having fine-grained control?
I think we will always have folks that want to force it on, i.e. the
MAP_SYNC user crowd. However, I think we might have some people what
will complain if they can't force it off. For example, I'm in the
process of killing off support for passing filesystem-dax mappings
through to guests because VFIO has the same "pin pages / fs-blocks
forever" problem as RDMA. Passing page cache through to a guest works
fine and it would be a shame if that silently stopped working in the
future. Given the page pinning constraint I'm not sure we can ever
support dynamically enabling DAX behind the user's back, at least not
until we kill off any "pin pages / fs-blocks forever" users, or
otherwise convert them to take a lease.
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Dave Jiang <dave.jiang@intel.com>,
Dave Chinner <david@fromorbit.com>,
linux-xfs <linux-xfs@vger.kernel.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-ext4 <linux-ext4@vger.kernel.org>,
linux-nvdimm@lists.01.org
Subject: Re: [PATCH 2 2/2] xfs: fix rt_dev usage for DAX
Date: Tue, 6 Feb 2018 16:19:12 -0800 [thread overview]
Message-ID: <CAPcyv4jQ+ATdVUdF32+uZwcnTZCQnUSMD1fLg14JrT870jaB7g@mail.gmail.com> (raw)
In-Reply-To: <20180206231915.GA26233@magnolia>
On Tue, Feb 6, 2018 at 3:19 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote:
> On Tue, Feb 06, 2018 at 03:32:00PM -0700, Dave Jiang wrote:
[..]
> The last time I paid much attention to DAX was the thread "re-enable XFS
> per-inode DAX"[1] last September. Motivating me to merge anything else
> into DAX involves convincing me that we (mm, fs, dax developers) have
> some kind of agreement about what we want the user-visible interfaces to
> DAX to look like. Namely:
>
> 0. On what level do we allow users / administrators to control usage of
> the dax paths? Can the hardware convey enough detail to the kernel that
> the kernel can make a reasonable decision on its own whether buffered or
> dax io make more sense? If so, can we please just have that? If not,
> why?
>
> 1. If we want to let users override whatever decision the kernel makes,
> how should we do this? One mount option that applies to everything,
> like ext4? Inheritable inode flags, like xfs? Do we have one to force
> it on even if the kernel doesn't want to? Do we have another to force
> it off even if the kernel wants to? Do we even want to go down this
> path? Can we get away with making the answer to Q0 "yes" and then see
> if anyone actually complains about not having fine-grained control?
I think we will always have folks that want to force it on, i.e. the
MAP_SYNC user crowd. However, I think we might have some people what
will complain if they can't force it off. For example, I'm in the
process of killing off support for passing filesystem-dax mappings
through to guests because VFIO has the same "pin pages / fs-blocks
forever" problem as RDMA. Passing page cache through to a guest works
fine and it would be a shame if that silently stopped working in the
future. Given the page pinning constraint I'm not sure we can ever
support dynamically enabling DAX behind the user's back, at least not
until we kill off any "pin pages / fs-blocks forever" users, or
otherwise convert them to take a lease.
next prev parent reply other threads:[~2018-02-07 0:13 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 20:32 [PATCH 2 1/2] dax: change bdev_dax_supported() to take a block_device as input Dave Jiang
2018-02-01 20:32 ` Dave Jiang
2018-02-01 20:32 ` Dave Jiang
2018-02-01 20:33 ` [PATCH 2 2/2] xfs: fix rt_dev usage for DAX Dave Jiang
2018-02-01 20:33 ` Dave Jiang
2018-02-01 23:28 ` Darrick J. Wong
2018-02-01 23:28 ` Darrick J. Wong
2018-02-01 23:28 ` Darrick J. Wong
2018-02-02 0:08 ` Dave Jiang
2018-02-02 0:08 ` Dave Jiang
2018-02-02 0:08 ` Dave Jiang
2018-02-02 0:38 ` Darrick J. Wong
2018-02-02 0:38 ` Darrick J. Wong
2018-02-02 0:38 ` Darrick J. Wong
2018-02-01 23:44 ` Dave Chinner
2018-02-01 23:44 ` Dave Chinner
2018-02-02 0:13 ` Dave Jiang
2018-02-02 0:13 ` Dave Jiang
2018-02-02 0:13 ` Dave Jiang
2018-02-02 3:20 ` Dave Chinner
2018-02-02 3:20 ` Dave Chinner
2018-02-02 3:20 ` Dave Chinner
2018-02-02 0:43 ` Darrick J. Wong
2018-02-02 0:43 ` Darrick J. Wong
2018-02-02 0:43 ` Darrick J. Wong
2018-02-02 3:36 ` Dave Chinner
2018-02-02 3:36 ` Dave Chinner
2018-02-06 22:32 ` Dave Jiang
2018-02-06 22:32 ` Dave Jiang
2018-02-06 22:32 ` Dave Jiang
2018-02-06 23:19 ` Darrick J. Wong
2018-02-06 23:19 ` Darrick J. Wong
2018-02-07 0:19 ` Dan Williams [this message]
2018-02-07 0:19 ` Dan Williams
2018-02-07 0:19 ` Dan Williams
2018-03-06 0:06 ` Ross Zwisler
2018-03-06 0:06 ` Ross Zwisler
2018-03-06 0:06 ` Ross Zwisler
2018-02-01 22:46 ` [PATCH 2 1/2] dax: change bdev_dax_supported() to take a block_device as input Darrick J. Wong
2018-02-01 22:46 ` Darrick J. Wong
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=CAPcyv4jQ+ATdVUdF32+uZwcnTZCQnUSMD1fLg14JrT870jaB7g@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.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.