From: "Theodore Ts'o" <tytso@mit.edu>
To: John Hubbard <jhubbard@nvidia.com>
Cc: lsf-pc@lists.linux-foundation.org,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
Christoph Hellwig <hch@lst.de>,
Jason Gary Gunthorpe <jgg@nvidia.com>,
Chaitanya Kulkarni <chaitanyak@nvidia.com>,
Matthew Wilcox <willy@infradead.org>,
Linux-MM <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [LSF/MM/BPF TOPIC] FOLL_PIN + file systems
Date: Tue, 1 Mar 2022 01:41:02 -0500 [thread overview]
Message-ID: <Yh2//uwOCPNVZPKB@mit.edu> (raw)
In-Reply-To: <c6e152ad-2b31-48cd-3d5e-c109d24a0e79@nvidia.com>
On Fri, Jan 28, 2022 at 05:47:47PM -0800, John Hubbard wrote:
> By the time we meet for LSF/MM/BPF in May, the Direct IO layer will
> likely be converted to use FOLL_PIN page pinning (that is, changed from
> using get_user_pages_fast(), to pin_user_pages_fast()).
>
> Direct IO conversion to FOLL_PIN was the last missing piece, and so the
> time is right to discuss how to use the output of all of this work
> (which is: the ability to call page_maybe_dma_pinned()), in order to fix
> one of the original problems that prompted FOLL_PIN's creation.
>
> That problem is: file systems do not currently tolerate having their
> pages pinned and DMA'd to/from. See [1] for an extensive background of
> some 11 LWN articles since 2018.
> ....
>
> I'll volunteer to present a few slides to provide the background and get
> the discussion started. It's critical to have filesystem people in
> attendance for this, such as Jan Kara, Dave Chinner, Christoph Hellwig,
> and many more that I won't try to list explicitly here. RDMA
> representation (Jason Gunthorpe, Leon Romanovsky, Chaitanya Kulkarni,
> and others) will help keep the file system folks from creating rules
> that break them "too much". And of course -mm folks. There are many
> people who have contributed to this project, so again, apologies for not
> listing everyone explicitly.
I'd definitely be interested in participating in this discussion,
following up on some e-mail threads that we've had on this subject.
Unfortunately a number of file system folks are listed above may not
be able to attend, so I really hope we can figure out some way to
allow remote participation for those people who aren't able to travel
due to various reasons, including corporate policies surrounding COVID.
- Ted
next prev parent reply other threads:[~2022-03-01 6:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-29 1:47 [LSF/MM/BPF TOPIC] FOLL_PIN + file systems John Hubbard
2022-03-01 6:41 ` Theodore Ts'o [this message]
2022-03-01 6:58 ` John Hubbard
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=Yh2//uwOCPNVZPKB@mit.edu \
--to=tytso@mit.edu \
--cc=chaitanyak@nvidia.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=willy@infradead.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.