Linux filesystem development
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Jeff Layton <jlayton@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Cc: Mike Snitzer <snitzer@kernel.org>,
	Trond Myklebust <trondmy@hammerspace.com>,
	Jens Axboe <axboe@kernel.dk>, Chris Mason <clm@meta.com>,
	Anna Schumaker <anna@kernel.org>
Subject: Re: performance r nfsd with RWF_DONTCACHE and larger wsizes
Date: Tue, 6 May 2025 14:16:34 -0400	[thread overview]
Message-ID: <d4d16122-5db6-473e-82dd-39e728796064@oracle.com> (raw)
In-Reply-To: <370dd4ae06d44f852342b7ee2b969fc544bd1213.camel@kernel.org>

On 5/6/25 1:40 PM, Jeff Layton wrote:
> FYI I decided to try and get some numbers with Mike's RWF_DONTCACHE
> patches for nfsd [1]. Those add a module param that make all reads and
> writes use RWF_DONTCACHE.
> 
> I had one host that was running knfsd with an XFS export, and a second
> that was acting as NFS client. Both machines have tons of memory, so
> pagecache utilization is irrelevant for this test.
> 
> I tested sequential writes using the fio-seq_write.fio test, both with
> and without the module param enabled.
> 
> These numbers are from one run each, but they were pretty stable over
> several runs:
> 
> # fio /usr/share/doc/fio/examples/fio-seq-write.fio
> 
> wsize=1M:
> 
> Normal:      WRITE: bw=1034MiB/s (1084MB/s), 1034MiB/s-1034MiB/s (1084MB/s-1084MB/s), io=910GiB (977GB), run=901326-901326msec
> DONTCACHE:   WRITE: bw=649MiB/s (681MB/s), 649MiB/s-649MiB/s (681MB/s-681MB/s), io=571GiB (613GB), run=900001-900001msec
> 
> DONTCACHE with a 1M wsize vs. recent (v6.14-ish) knfsd was about 30%
> slower. Memory consumption was down, but these boxes have oodles of
> memory, so I didn't notice much change there.
> 
> Chris suggested that the write sizes were too small in this test, so I
> grabbed Chuck's patches to increase the max RPC payload size [2] to 4M,
> and patched the client to allow a wsize that big:
> 
> wsize=4M:
> 
> Normal:       WRITE: bw=1053MiB/s (1104MB/s), 1053MiB/s-1053MiB/s (1104MB/s-1104MB/s), io=930GiB (999GB), run=904526-904526msec
> DONTCACHE:    WRITE: bw=1191MiB/s (1249MB/s), 1191MiB/s-1191MiB/s (1249MB/s-1249MB/s), io=1050GiB (1127GB), run=902781-902781msec
> 
> Not much change with normal buffered I/O here, but DONTCACHE is faster
> with a 4M wsize. My suspicion (unconfirmed) is that the dropbehind flag
> ends up causing partially-written large folios in the pagecache to get
> written back too early, and that slows down later writes to the same
> folios.

My feeling is that at this point, the NFSD read and write paths are not
currently tuned for large folios -- they break every I/O into single
pages.


> I wonder if we need some heuristic that makes generic_write_sync() only
> kick off writeback immediately if the whole folio is dirty so we have
> more time to gather writes before kicking off writeback?

Mike has suggested that NFSD should limit the use RWF_UNCACHED to
WRITE requests with large payloads (for some arbitrary definition of
"large").


> This might also be a good reason to think about a larger rsize/wsize
> limit in the client.
> 
> I'd like to also test reads with this flag, but I'm currently getting
> back that EOPNOTSUPP error when I try to test them.

That's expected for that patch series.

But I have to ask: what problem do you expect RWF_UNCACHED to solve?


> [1]: https://lore.kernel.org/linux-nfs/20250220171205.12092-1-
> snitzer@kernel.org/
> [2]: https://lore.kernel.org/linux-nfs/20250428193702.5186-15-
> cel@kernel.org/


-- 
Chuck Lever

  reply	other threads:[~2025-05-06 18:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-06 17:40 performance r nfsd with RWF_DONTCACHE and larger wsizes Jeff Layton
2025-05-06 18:16 ` Chuck Lever [this message]
2025-05-06 18:30   ` Jeff Layton
2025-05-06 22:31 ` Dave Chinner
2025-05-07  0:06   ` Jeff Layton
2025-05-07  2:50     ` Dave Chinner
2025-05-07 13:43       ` Chuck Lever
2025-05-08  1:13         ` Dave Chinner
2025-05-07 21:50       ` Mike Snitzer
2025-05-08  0:09         ` Jeff Layton
2025-05-08  2:05           ` Dave Chinner
2025-05-08  1:50         ` Dave Chinner

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=d4d16122-5db6-473e-82dd-39e728796064@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=anna@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=clm@meta.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=snitzer@kernel.org \
    --cc=trondmy@hammerspace.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox