From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>
Cc: "jgg@mellanox.com" <jgg@mellanox.com>,
"hch@infradead.org" <hch@infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"mhocko@kernel.org" <mhocko@kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: [LSF/MM TOPIC] Filesystem-DAX, page-pinning, and RDMA
Date: Thu, 25 Jan 2018 04:01:43 +0000 [thread overview]
Message-ID: <1516852902.3724.4.camel@wdc.com> (raw)
In-Reply-To: <CAPcyv4gQNM9RbTbRWKnG6Vby_CW9CJ9EZTARsVNi=9cas7ZR2A@mail.gmail.com>
On Wed, 2018-01-24 at 19:56 -0800, Dan Williams wrote:
> The get_user_pages_longterm() api was recently added as a stop-gap
> measure to prevent applications from growing dependencies on the
> ability to to pin DAX-mapped filesystem blocks for RDMA indefinitely
> with no ongoing coordination with the filesystem. This 'longterm'
> pinning is also problematic for the non-DAX VMA case where the core-mm
> needs a time bounded way to revoke a pin and manipulate the physical
> pages. While existing RDMA applications have already grown the
> assumption that they can pin page-cache pages indefinitely, the fact
> that we are breaking this assumption for filesystem-dax presents an
> opportunity to deprecate the 'indefinite pin' mechanisms and move to a
> general interface that supports pin revocation.
>
> While RDMA may grow an explicit Infiniband-verb for this 'memory
> registration with lease' semantic, it seems that this problem is
> bigger than just RDMA. At LSF/MM it would be useful to have a
> discussion between fs, mm, dax, and RDMA folks about addressing this
> problem at the core level.
>
> Particular people that would be useful to have in attendance are
> Michal Hocko, Christoph Hellwig, and Jason Gunthorpe (cc'd).
Is on demand paging sufficient as a solution for your use case or do
you perhaps need something different? See also
https://www.openfabrics.org/images/eventpresos/workshops2013/2013_Workshop_Tues_0930_liss_odp.pdf
Thanks,
Bart.
next prev parent reply other threads:[~2018-01-25 4:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 3:56 [LSF/MM TOPIC] Filesystem-DAX, page-pinning, and RDMA Dan Williams
2018-01-25 4:01 ` Bart Van Assche [this message]
2018-01-25 7:02 ` Dan Williams
2018-01-25 16:08 ` Jason Gunthorpe
2018-01-25 16:47 ` hch
2018-01-25 7:23 ` Christoph Hellwig
2018-01-25 16:08 ` Jason Gunthorpe
2018-01-25 16:47 ` Christoph Hellwig
2018-01-27 2:50 ` Dan Williams
2019-04-05 23:01 ` Jason Gunthorpe
2018-01-29 23:33 ` Jerome Glisse
2018-02-01 23:27 ` Jason Gunthorpe
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=1516852902.3724.4.camel@wdc.com \
--to=bart.vanassche@wdc.com \
--cc=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=jgg@mellanox.com \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@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 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).