Re: [PATCH v6 05/13] NFS: Improve algorithm for falling back to uncached readdir

[Trond Myklebust <trondmy@hammerspace.com>]

On Mon, 2022-02-21 at 11:45 -0500, Benjamin Coddington wrote:
> On 21 Feb 2022, at 11:08, trondmy@kernel.org wrote:
> 
> > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > 
> > When reading a very large directory, we want to try to keep the
> > page
> > cache up to date if doing so is inexpensive. Right now, we will try
> > to
> > refill the page cache if it is non-empty, irrespective of whether
> > or not
> > doing so is going to take a long time.
> > 
> > Replace that algorithm with something that looks at how many times
> > we've
> > refilled the page cache without seeing a cache hit.
> 
> Hi Trond, I've been following your work here - thanks for it.
> 
> I'm wondering if there might be a regression on this patch for the
> case
> where two or more directory readers are part way through a large
> directory
> when the pagecache is truncated.  If I'm reading this correctly,
> those
> readers will stop caching after 5 fills and finish the remainder of
> their
> directory reads in the uncached mode.
> 
> Isn't there an OP amplification per reader in this case?
> 

Depends... In the old case, we basically stopped doing uncached readdir
if a third process starts filling the page cache again. In particular,
this means we were vulnerable to restarting over and over once page
reclaim starts to kick in for very large directories.

In this new one, we have each process give it a try (5 fills each), and
then fallback to uncached. Yes, there will be corner cases where this
will perform less well than the old algorithm, but it should also be
more deterministic.

I am open to suggestions for better ways to determine when to cut over
to uncached readdir. This is one way, that I think is better than what
we have, however I'm sure it can be improved upon.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com