]> git.apps.os.sepia.ceph.com Git - ceph-client.git/commit
[DO NOT MERGE] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per...
authorJeff Layton <jlayton@redhat.com>
Thu, 26 Jan 2017 13:01:13 +0000 (08:01 -0500)
committerIlya Dryomov <idryomov@gmail.com>
Thu, 3 May 2018 15:56:38 +0000 (17:56 +0200)
commit835347f00ba1f11f7022b8168c42cc54a87f049d
tree4a1a4e6b51847a0e728f96dfad5be2cd762cf2f6
parent6da6c0db5316275015e8cc2959f12a17584aeb64
[DO NOT MERGE] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call

Currently, iov_iter_get_pages_alloc will only ever operate on the first
vector that iterate_all_kinds hands back. Most of the callers however
would like to have as long a set of pages as possible, to allow for
fewer, but larger I/Os.

When the previous vector ends on a page boundary and the current one
begins on one, we can continue to add more pages.

Change the function to first scan the iov_iter to see how long an
array of pages we could create from the current position up to the
maxsize passed in. Then, allocate an array that large and start
filling in that many pages.

The main impetus for this patch is to rip out a swath of code in ceph
that tries to do this but that doesn't handle ITER_BVEC correctly.

NFS also uses this function and this also allows the client to do larger
I/Os when userland passes down an array of page-aligned iovecs in an
O_DIRECT request. This should also make splice writes into an O_DIRECT
file on NFS use larger I/Os, since that's now done by passing down an
ITER_BVEC representing the data to be written.

I believe the other callers (lustre and 9p) may also benefit from this
change, but I don't have a great way to verify that.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
lib/iov_iter.c