Re: [PATCH v2 0/8] nfsd: duplicate reply cache overhaul

Jeff Layton
2013-02-05T15:58:10Z

On Tue, 5 Feb 2013 10:15:05 -0500
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Mon, Feb 04, 2013 at 08:17:59AM -0500, Jeff Layton wrote:
> > This patchset is a first pass at fixing this. Instead of simply keeping
> > a cache of the last 1024 entries, it allows nfsd to grow and shrink the
> > DRC dynamically.
>
> One other thing I think we should try is to organize the cache per
> client address and evict cache entries from clients with more entries
> first, on the theory that:
>
> - There are diminishing returns from keeping huge numbers of
> entries from a single client: a client that has sent us lots
> of new requests is likely to have processed replies to the
> older ones.
>

Ok, but you'd need to be careful here. You don't want to drop any entry
before the client has had a chance to retransmit the request, but we
don't have a way to know what timeo= value the client is using.

> - We should still try to hang on to a few of the most recent
> entries from a client that hasn't made any requests recently,
> because such a client may have just temporarily lost contact,
> in which case it's particularly likely to need to retry a
> request, and we don't want its entries pushed out by clients
> that remain active.
>

Sounds tricky to get the heuristics right, but interesting. Maybe we
can try to hash them out while we're at cthon?

--
Jeff Layton <jlayton@redhat.com>