Re: [PATCH RFC] nfsd: report length of the largest hash chain in reply cache stats

[Chuck Lever <chuck.lever@oracle.com>]

On Feb 17, 2013, at 11:00 AM, J. Bruce Fields <bfields@fieldses.org> wrote:

> On Sat, Feb 16, 2013 at 12:18:18PM -0500, Chuck Lever wrote:
>> 
>> On Feb 16, 2013, at 8:39 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
>>> With a per-client maximum number of entries, sizing the hash tables
>>> should be easier.
>> When a server has only one client, should that client be allowed to
>> maximize the use of a server's resources (eg, use all of the DRC
>> resource the server has available)?
> 
> I've been assuming there's rapidly diminishing returns to caching a lot
> of replies to a single client.  But that might not be true--I guess a
> busy UDP client with a long retry timeout might benefit from a large
> cache?

I was thinking that the possible value of holding a reply diminishes the _longer_ you hold it.  The number of replies held depends then on how busy each client is, and of course, how much memory is available to hold cached replies.

Jeff's metrics may help us sort this out.

> 
>> How about when a server has one active client and multiple quiescent
>> clients?
> 
> I think there's a chance in that case that one of the quiescent clients
> is experiencing a temporary network problem, in which case we may want
> to preserve a few entries for them even if the active client's activity
> would normally evict them.

OK, sure.  So, we might express that as a lower bound on the number of replies cached per client?  Or would we express it as an upper bound on the age of each cached reply?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com