Re: [PATCH v4 0/5] NFSD: Add support for the v4.2 READ_PLUS operation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 26, 2020 at 5:54 PM J. Bruce Fields <bfields@xxxxxxxxxx> wrote:
>
> On Mon, Aug 17, 2020 at 12:53:05PM -0400, schumaker.anna@xxxxxxxxx wrote:
> > From: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx>
> >
> > These patches add server support for the READ_PLUS operation, which
> > breaks read requests into several "data" and "hole" segments when
> > replying to the client.
> >
> > - Changes since v3:
> >   - Combine first two patches related to xdr_reserve_space_vec()
> >   - Remove unnecessary call to svc_encode_read_payload()
> >
> > Here are the results of some performance tests I ran on some lab
> > machines.
>
> What's the hardware setup (do you know network and disk bandwidth?).

I used iperf to benchmark the network, and it said it transferred 1.10
GBytes with a bandwidth of 941 Mbits/sec

I ran hdparm -tT to benchmark reads on the disk and it said this:
Timing cached reads:   13394 MB in  2.00 seconds = 6713.72 MB/sec
Timing buffered disk reads: 362 MB in 3.00 seconds = 120.60 MB/sec

>
> > I tested by reading various 2G files from a few different underlying
> > filesystems and across several NFS versions. I used the `vmtouch` utility
> > to make sure files were only cached when we wanted them to be. In addition
> > to 100% data and 100% hole cases, I also tested with files that alternate
> > between data and hole segments. These files have either 4K, 8K, 16K, or 32K
> > segment sizes and start with either data or hole segments. So the file
> > mixed-4d has a 4K segment size beginning with a data segment, but mixed-32h
> > has 32K segments beginning with a hole. The units are in seconds, with the
> > first number for each NFS version being the uncached read time and the second
> > number is for when the file is cached on the server.
>
> The only numbers that look really strange are in the btrfs uncached
> case, in the data-only case and the mixed case that start with a hole.
> Do we have any idea what's up there?

I'm not really sure. BTRFS does some work to make sure the page cache
is synced up with their internal extent representation as part of
llseek, so my guess is something related to that (But it's been a
while since I looked into that code, so I'm not sure if that's still
how it works)

Anna

>
> --b.
>
> > Read Plus Results (btrfs):
> >   data
> >    :... v4.1 ... Uncached ... 21.317 s, 101 MB/s, 0.63 s kern, 2% cpu
> >    :    :....... Cached ..... 18.252 s, 118 MB/s, 0.67 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 28.665 s,  75 MB/s, 0.65 s kern, 2% cpu
> >         :....... Cached ..... 18.253 s, 118 MB/s, 0.66 s kern, 3% cpu
> >   hole
> >    :... v4.1 ... Uncached ... 18.256 s, 118 MB/s, 0.70 s kern,  3% cpu
> >    :    :....... Cached ..... 18.254 s, 118 MB/s, 0.73 s kern,  4% cpu
> >    :... v4.2 ... Uncached ...  0.851 s, 2.5 GB/s, 0.72 s kern, 84% cpu
> >         :....... Cached .....  0.847 s, 2.5 GB/s, 0.73 s kern, 86% cpu
> >   mixed-4d
> >    :... v4.1 ... Uncached ... 56.857 s,  38 MB/s, 0.76 s kern, 1% cpu
> >    :    :....... Cached ..... 18.252 s, 118 MB/s, 0.72 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 54.455 s,  39 MB/s, 0.73 s kern, 1% cpu
> >         :....... Cached .....  9.215 s, 233 MB/s, 0.68 s kern, 7% cpu
> >   mixed-8d
> >    :... v4.1 ... Uncached ... 36.641 s,  59 MB/s, 0.68 s kern, 1% cpu
> >    :    :....... Cached ..... 18.252 s, 118 MB/s, 0.70 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 33.205 s,  65 MB/s, 0.67 s kern, 2% cpu
> >         :....... Cached .....  9.172 s, 234 MB/s, 0.65 s kern, 7% cpu
> >   mixed-16d
> >    :... v4.1 ... Uncached ... 28.653 s,  75 MB/s, 0.72 s kern, 2% cpu
> >    :    :....... Cached ..... 18.252 s, 118 MB/s, 0.70 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 25.748 s,  83 MB/s, 0.71 s kern, 2% cpu
> >         :....... Cached .....  9.150 s, 235 MB/s, 0.64 s kern, 7% cpu
> >   mixed-32d
> >    :... v4.1 ... Uncached ... 28.886 s,  74 MB/s, 0.67 s kern, 2% cpu
> >    :    :....... Cached ..... 18.252 s, 118 MB/s, 0.71 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 24.724 s,  87 MB/s, 0.74 s kern, 2% cpu
> >         :....... Cached .....  9.140 s, 235 MB/s, 0.63 s kern, 6% cpu
> >   mixed-4h
> >    :... v4.1 ... Uncached ...  52.181 s,  41 MB/s, 0.73 s kern, 1% cpu
> >    :    :....... Cached .....  18.252 s, 118 MB/s, 0.66 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 150.341 s,  14 MB/s, 0.72 s kern, 0% cpu
> >         :....... Cached .....   9.216 s, 233 MB/s, 0.63 s kern, 6% cpu
> >   mixed-8h
> >    :... v4.1 ... Uncached ... 36.945 s,  58 MB/s, 0.68 s kern, 1% cpu
> >    :    :....... Cached ..... 18.252 s, 118 MB/s, 0.65 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 79.781 s,  27 MB/s, 0.68 s kern, 0% cpu
> >         :....... Cached .....  9.172 s, 234 MB/s, 0.66 s kern, 7% cpu
> >   mixed-16h
> >    :... v4.1 ... Uncached ... 28.651 s,  75 MB/s, 0.73 s kern, 2% cpu
> >    :    :....... Cached ..... 18.252 s, 118 MB/s, 0.66 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 47.428 s,  45 MB/s, 0.71 s kern, 1% cpu
> >         :....... Cached .....  9.150 s, 235 MB/s, 0.67 s kern, 7% cpu
> >   mixed-32h
> >    :... v4.1 ... Uncached ... 28.618 s,  75 MB/s, 0.69 s kern, 2% cpu
> >    :    :....... Cached ..... 18.252 s, 118 MB/s, 0.70 s kern, 3% cpu
> >    :... v4.2 ... Uncached ... 38.813 s,  55 MB/s, 0.67 s kern, 1% cpu
> >         :....... Cached .....  9.140 s, 235 MB/s, 0.61 s kern, 6% cpu
>



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux