On 27 Feb 2022, at 18:12, trondmy@xxxxxxxxxx wrote: > From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > > The heuristic for readdirplus is designed to try to detect 'ls -l' and > similar patterns. It does so by looking for cache hit/miss patterns in > both the attribute cache and in the dcache of the files in a given > directory, and then sets a flag for the readdirplus code to interpret. > > The problem with this approach is that a single attribute or dcache miss > can cause the NFS code to force a refresh of the attributes for the > entire set of files contained in the directory. > > To be able to make a more nuanced decision, let's sample the number of > hits and misses in the set of open directory descriptors. That allows us > to set thresholds at which we start preferring READDIRPLUS over regular > READDIR, or at which we start to force a re-read of the remaining > readdir cache using READDIRPLUS. I like this patch very much. The heuristic doesn't kick-in until "ls -l" makes its second call into nfs_readdir(), and for my filenames with 8 chars, that means that there are about 5800 GETATTRs generated before we clean the cache to do more READDIRPLUS. That's a large number to compound on connection latency. We've already got some complaints that folk's 2nd "ls -l" takes "so much longer" after 1a34c8c9a49e. Can we possibly limit our first pass through nfs_readdir() so that the heuristic takes effect sooner? Ben
