Re: [RFC PATCH 2/2] NFSD: Add asynchronous write throttling support

[Mike Snitzer <snitzer@kernel.org>]

On Wed, Jan 07, 2026 at 09:42:58AM -0500, Chuck Lever wrote:
> On 1/7/26 3:00 AM, Christoph Hellwig wrote:
> > On Fri, Dec 19, 2025 at 09:11:05AM -0500, Chuck Lever wrote:
> >> From: Chuck Lever <chuck.lever@oracle.com>
> >>
> >> When memory pressure occurs during buffered writes, the traditional
> >> approach is for balance_dirty_pages() to put the writing thread to
> >> sleep until dirty pages are flushed. For NFSD, this means server
> >> threads block waiting for I/O, reducing overall server throughput.
> >>
> >> Add support for asynchronous write throttling using the BDP_ASYNC
> >> flag to balance_dirty_pages_ratelimited_flags(). When enabled via:
> >>
> >>   /sys/kernel/debug/nfsd/write_async_throttle
> > 
> > Let me reiterate that I really, really hate all this magic debugs-fs
> > enabled features.  Either they are gnuinely useful (think this would
> > be such a thing) and they should be enabled unconditionally, or they
> > are tradeoffs and should have a proper tunable not hidden in debugfs.
> 
> The use of debugfs here is because we don't yet have a coherent design
> in mind -- this new facility is entirely experimental, and we need a
> way to enable and disable it to make good comparisons, without making
> immutable changes to the actual NFSD administrative interface.
> 
> "The RFC sign out front should have told ya."
> 
> But I agree, in the long term I most prefer no new administrative
> controls -- it should just work if at all possible.
> 
> 
> >> NFSD checks memory pressure before attempting buffered writes. If
> >> balance_dirty_pages_ratelimited_flags() returns -EAGAIN (indicating
> >> memory exhaustion), NFSD returns NFS4ERR_DELAY (or NFSERR_JUKEBOX for
> >> NFSv3) to the client instead of blocking.
> >>
> >> This allows clients to back off and retry rather than having server
> >> threads tied up waiting for writeback. The setting defaults to 0
> >> (synchronous throttling) and can be combined with write_throttle for
> >> layered throttling strategies.
> >>
> >> Note: NFSv2 does not support NFSERR_JUKEBOX, so async throttling is
> >> automatically disabled for NFSv2 requests regardless of the setting.
> > 
> > This all seems very useful to me.  But it really needs to show numbers
> > on how it helps.
> 
> Well if I can get this into operational shape, perhaps J. Flynn would
> be interested in trying it out for us.
> 
> I'm happy to run with this one and drop (or postpone) 1/2, if that is
> your assessment.

Probably a good start.  Definitely looks useful and worth measuring to
see if buffered IO improves.

I can include it in a test kernel for Jon Flynn once you're happy with
the patch and would like further testing (fyi I've rebased to latest
6.18-stable but Jon hasn't done baseline testing of it yet, so we
could kill 2 birds once ready).

Thanks,
Mike

ps. Jon, for further context see Chuck's original 2/2 patch:
https://lore.kernel.org/linux-nfs/20251219141105.1247093-3-cel@kernel.org/

And his cover letter:
https://lore.kernel.org/linux-nfs/20251219141105.1247093-1-cel@kernel.org/
Also patch 1/2, but consensus seems to be "focus on 2/2 first":
https://lore.kernel.org/linux-nfs/20251219141105.1247093-2-cel@kernel.org/