On Tue, 5 Feb 2013 10:15:05 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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@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
