]> err.no Git - linux-2.6/commit
NFS: Eliminate nfs_get_user_pages()
authorChuck Lever <cel@netapp.com>
Tue, 20 Jun 2006 16:56:49 +0000 (12:56 -0400)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Sat, 24 Jun 2006 17:11:39 +0000 (13:11 -0400)
commit06cf6f2ed0b19629700794727d86ed57b9c0583e
tree20630465974dc9391af486d8609aae077701b596
parent9c93ab7dff5eb22027ab15010557bb73f9b44c99
NFS: Eliminate nfs_get_user_pages()

Neil Brown observed that the kmalloc() in nfs_get_user_pages() is more
likely to fail if the I/O is large enough to require the allocation of more
than a single page to keep track of all the pinned pages in the user's
buffer.

Instead of tracking one large page array per dreq/iocb, track pages per
nfs_read/write_data, just like the cached I/O path does.  An array for
pages is already allocated for us by nfs_readdata_alloc() (and the write
and commit equivalents).

This is also required for adding support for vectored I/O to the NFS direct
I/O path.

The original reason to pin the user buffer and allocate all the NFS data
structures before trying to schedule I/O was to ensure all needed resources
are allocated on the client before starting to send requests.  This reduces
the chance that resource exhaustion on the client will cause a short read
or write.

On the other hand, for an application making very large application I/O
requests, this means that it will be nearly impossible for the application
to make forward progress on a resource-limited client.

Thus, moving the buffer pinning functionality into the I/O scheduling
loops should be good for scalability.  The next patch will do the same for
NFS data structure allocation.

Signed-off-by: Chuck Lever <cel@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
fs/nfs/direct.c
include/linux/nfs_xdr.h