On 23 Feb 2022, at 16:13, trondmy@xxxxxxxxxx wrote: > From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > > Instead of using a linear index to address the pages, use the cookie of > the first entry, since that is what we use to match the page anyway. > > This allows us to avoid re-reading the entire cache on a seekdir() type > of operation. The latter is very common when re-exporting NFS, and is a > major performance drain. > > The change does affect our duplicate cookie detection, since we can no > longer rely on the page index as a linear offset for detecting whether > we looped backwards. However since we no longer do a linear search > through all the pages on each call to nfs_readdir(), this is less of a > concern than it was previously. > The other downside is that invalidate_mapping_pages() no longer can use > the page index to avoid clearing pages that have been read. A subsequent > patch will restore the functionality this provides to the 'ls -l' > heuristic. This is cool, but one reason I did not explore this was that the page cache index uses XArray, which is optimized for densly clustered indexes. This particular sentence in the documentation was enough to scare me away: "The XArray implementation is efficient when the indices used are densely clustered; hashing the object and using the hash as the index will not perform well." However, the "not perform well" may be orders of magnitude smaller than anthing like RPC. Do you have concerns about this? Another option might be to flag the context after a seekdir, which would trigger a shift in the page_index or "turn on" hashed indexes, however that's really only going to improve the re-export case with v4 or cached fds. Or maybe the /first/ seekdir on a context sets its own offset into the pagecache - that could be a hash, and pages are filled from there. Hmm.. Ben
