From: John Hubbard <jhubbard@nvidia.com>
To: David Hildenbrand <david@redhat.com>,
Jens Axboe <axboe@kernel.dk>, Jan Kara <jack@suse.cz>,
Christoph Hellwig <hch@infradead.org>,
Dave Chinner <dchinner@redhat.com>,
"Darrick J . Wong" <djwong@kernel.org>,
Theodore Ts'o <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Miklos Szeredi <miklos@szeredi.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Chaitanya Kulkarni <kch@nvidia.com>
Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-mm@kvack.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/7] block, fs: convert Direct IO to FOLL_PIN
Date: Fri, 25 Feb 2022 13:10:53 -0800 [thread overview]
Message-ID: <9a39e80c-d68f-aad9-b68d-6e578d7b8839@nvidia.com> (raw)
In-Reply-To: <ad29be74-d296-a9fb-41d7-00d2ba15ea5c@redhat.com>
On 2/25/22 05:12, David Hildenbrand wrote:
> vmsplice is another candidate that uses iov_iter_get_pages() and should
Yes.
> be converted to FOLL_PIN. For that particular user, we have to also pass
> FOLL_LONGTERM -- vmsplice as it stands can block memory hotunplug / CMA
> / ... for all eternity.
>
Oh, thanks for pointing that out. I was thinking about Direct IO, and
would have overlooked that vmsplice need FOLL_LONGTERM.
I'm still quite vague about which parts of vmsplice are in pipe buffers
(and therefore will *not* get FOLL_PIN pages) and which are in user space
buffers. Just haven't spent enough time with vmsplice yet, hopefully it
will clear up with some study of the code.
thanks,
--
John Hubbard
NVIDIA
prev parent reply other threads:[~2022-02-25 21:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 8:50 [RFC PATCH 0/7] block, fs: convert Direct IO to FOLL_PIN John Hubbard
2022-02-25 8:50 ` [RFC PATCH 1/7] mm/gup: introduce pin_user_page() John Hubbard
2022-02-28 13:27 ` David Hildenbrand
2022-02-28 21:14 ` John Hubbard
2022-03-01 8:11 ` David Hildenbrand
2022-03-01 8:40 ` John Hubbard
2022-03-01 9:30 ` David Hildenbrand
2022-02-25 8:50 ` [RFC PATCH 2/7] block: add dio_w_*() wrappers for pin, unpin user pages John Hubbard
2022-02-25 8:50 ` [RFC PATCH 3/7] block, fs: assert that key paths use iovecs, and nothing else John Hubbard
2022-02-25 8:50 ` [RFC PATCH 4/7] block, bio, fs: initial pin_user_pages_fast() changes John Hubbard
2022-02-25 8:50 ` [RFC PATCH 5/7] NFS: direct-io: convert to FOLL_PIN pages John Hubbard
2022-02-25 8:50 ` [RFC PATCH 6/7] fuse: convert direct IO paths to use FOLL_PIN John Hubbard
2022-02-25 8:50 ` [RFC PATCH 7/7] block, direct-io: flip the switch: use pin_user_pages_fast() John Hubbard
2022-02-25 12:05 ` [RFC PATCH 0/7] block, fs: convert Direct IO to FOLL_PIN Jan Kara
2022-02-25 16:14 ` Chaitanya Kulkarni
2022-02-25 16:40 ` Jan Kara
2022-02-25 19:36 ` John Hubbard
2022-02-25 22:20 ` John Hubbard
2022-02-25 13:12 ` David Hildenbrand
2022-02-25 21:10 ` John Hubbard [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=9a39e80c-d68f-aad9-b68d-6e578d7b8839@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=david@redhat.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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.