On Tue, 11 Oct 2022, Chuck Lever III wrote: > > On Oct 10, 2022, at 8:16 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > On Fri, 07 Oct 2022, Chuck Lever wrote: > >> > >> -static unsigned int file_hashval(struct svc_fh *fh) > >> +/* > >> + * The returned hash value is based solely on the address of an in-code > >> + * inode, a pointer to a slab-allocated object. The entropy in such a > >> + * pointer is concentrated in its middle bits. > > > > I think you need more justification than that for throwing away some of > > the entropy, even if you don't think it is much. > > We might have that justification: > > https://lore.kernel.org/linux-nfs/YrUFbLJ5uVbWtZbf@ZenIV/ > > Actually I believe we are not discarding /any/ entropy in > this function. The bits we discard are invariant. > > And, note that this is exactly the same situation we just merged > in the filecache overhaul, and is a common trope amongst other > hash tables that base their function on the inode's address. Common? I searched for ">> *L1_CACHE_SHIFT". Apart from the nfsd filecache you mentioned I find two. One in quota and one in reiserfs. Both work with traditional hash tables which are more forgiving of longer chains. Do you have other evidence of this being a common trope? Thanks, NeilBrown