On Sun, 17 Feb 2013 11:00:56 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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? > Yes, or one with a massively parallel workload and poor slot-table implementation that just sprays tons of requests at the server? > > 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. > Cache eviction policy is really orthogonal to how we organize it for efficient lookups. Currently, cache entries sit in a hash table for lookups, and on a LRU list for eviction. We can certainly change either or both. I think the trick here is to nail down what semantics you want for the cache and then look at how best to organize it to achieve that. OTOH, maybe we should see whether this is really a problem first before we go and try to fix anything. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
