Re: [lkp] [nfsd] 4aac1bf05b: -2.9% fsmark.files_per_sec

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Oct 01, 2015 at 09:17:42AM +1000, Dave Chinner wrote:
> Inode pointers have no entropy in the lower 9-10 bits because of
> their size, and being allocated from a slab they are all going to
> have the same set of values in the next 3-4 bits (i.e. offset into
> the slab page which is defined by sizeof(inode)).  Pointers also
> have very similar upper bits, too, because they are all in kernel
> memory.
> 
> hash_64 trys to fold all the entropy from the lower bits into into
> the upper bits and then takes the result from the upper bits. Hence
> if there is no entropy in either the lower or upper bits to start
> with, then the hash may not end up with much entropy in it at all...

So we have something hash_ptr() that turns out to be terrible at hashing
pointers?  Argh.

(I understand you're saying this isn't necessarily the case for all
pointers, but inode pointers on their own seem likely to be a common
case, and there must be many more that are similar.)

--b.

> 
> FWIW, see fs/inode.c::hash() to see how the fs code hashes inode
> numbers (called from insert_inode_hash()). It's very different
> because because inode numbers have the majority of their entropy in
> the lower bits and (usually) none in the upper bits...
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com