On Mon, Feb 18, 2013 at 09:21:34AM -0500, Jeff Layton wrote: > 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? I believe we pin cache entries while the request is in progress and timestamp and insert into the lru when when we send the reply--so the parallelism doesn't matter so much, in the sense that we're not going to for example get a big slow write operation evicted by a bunch of quick concurrent getattrs. What matters is: from the time we send a reply, to the time the client retries, how many more requests does the client send? > > > 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. Yeah. --b. -- 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
