Re: [PATCH v3 0/5] NFS: Add READ_PLUS support

[bfields@fieldses.org (J. Bruce Fields)]

On Mon, Mar 16, 2015 at 05:17:41PM -0400, Anna Schumaker wrote:
> These patches add client support for the NFS v4.2 operation READ_PLUS.  This
> operation is triggered by doing any kind of read on a NFS v4.2 mounted
> filesystem.  `
> 
> I tested these patches using xfstests and compared the runtime between NFS
> v4.1, NFS v4.2 without READ_PLUS, and NFS v4.2 with READ_PLUS.  Here are
> the results:

These are interesting but don't tell us much on their own.  As far as I
know xfstests isn't really intended to be used for performance
comparisons, and there are some mysteries here:

>    Test     |   v4.1    | no READ_PLUS |  READ_PLUS
> ---------------------------------------------------
> generic/013 | 135s      |    143s      |    123s

This is an fsstress run.  Looking quickly at ltp/fsstress.c, I see it
can do fallocate calls, so presumably that explains the difference.

> generic/075 |   4s      |     11s      |      4s

Ditto for fsx.

> generic/091 |   9s      |     16s      |     15s
> generic/112 |   4s      |      7s      |      6s
> generic/127 |  62s      |    117s      |    114s

fsx again; this one must really have a ton of fallocate calls?  Might be
interesting to look at strace or /proc/self/mountstats to confirm that.

> generic/213 | [not run] |      1s      |      1s
> generic/214 | [not run] |      0s      |      0s
> generic/228 | [not run] |      1s      |      2s
> generic/236 |   1s      |      1s      |      1s
> generic/263 |   4s      |      6s      |      8s
> generic/285 |   0s      |      1s      |      3s
> generic/315 | [not run] |      2s      |      1s
> ---------------------------------------------------
> Total       |  3:47.47  |    5:11.85   |  4:43.77

I'm already inclined to believe that the bandwidth savings are more
important than zero-copy in the bad cases.  And the xfstests timings
count for something.  But I'd still rather see more of an argument.

It'd be interesting to see the best possible case (reading a large file
that's all one hole), and the worst (reading a file with alternating 4K
data and holes?).

--b.

> 
> 
> Using the READ_PLUS operation does have an impact on reading sparse
> files over the network.  There is still a big difference between v4.1
> and v4.2 runtimes, but this looks to be a result of fallocate() tests
> that only run over v4.2.
> 
> 
> Changes since v2:
> - Merge together patches adding DATA and HOLE segment support.
> - Simplify hole zeroing code by using the zero_user_segment() function.
> 
> These patches and the corresponding server changes are available in the
> [read_plus] branch of
> 
> 	git://git.linux-nfs.org/projects/anna/linux-nfs.git
> 
> Questions?  Comments?  Thoughts?
> 
> Anna
> 
> 
> Anna Schumaker (5):
>   SUNRPC: Split out a function for setting current page
>   SUNRPC: Add the ability to expand holes in data pages
>   NFS: Add basic READ_PLUS support
>   SUNRPC: Add the ability to shift data to a specific offset
>   NFS: Add support for decoding multiple segments
> 
>  fs/nfs/nfs42xdr.c          | 162 ++++++++++++++++++++++++++++++
>  fs/nfs/nfs4proc.c          |  30 +++++-
>  fs/nfs/nfs4xdr.c           |   1 +
>  include/linux/nfs4.h       |   1 +
>  include/linux/nfs_fs_sb.h  |   1 +
>  include/linux/nfs_xdr.h    |   2 +-
>  include/linux/sunrpc/xdr.h |   2 +
>  net/sunrpc/xdr.c           | 240 ++++++++++++++++++++++++++++++++++++++++++++-
>  8 files changed, 434 insertions(+), 5 deletions(-)
> 
> -- 
> 2.3.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html