On Wed, Mar 30, 2022 at 4:18 PM Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote:
>
> Hmm... No there doesn't appear to be a huge difference between the two.
Ok, thanks for checking. It's basically what I would have expected,
both models really just depend on a reasonable mixing and shuffling of
bits in the word, and it really looks like they have very similar
collision behavior.
At some point even with equivalent functions you obviously end up with
just random differences that just depend on the input set and prue
luck.
But at least based on your numbers, it does look like they really are
equivalent, and hash_64() certainly doesn't look any worse.
All the extra work xxhash() does should matter mainly for
(a) using more final bits of the hash (ir not reducing them in the end)
(b) all the cases where you have much more input than one single word
Here, (b) obviously isn't an issue.
And that (a) is by design - those default kernel hash() functions are
literally designed for generating the index for hash tables, and so
expects that final reduction in size.
As a result, unlike xxhash(), it doesn't try to mix in bits in the low
bits, because it knows those will be shifted away in the use-case it's
designed for (the hash() reduction in bits always takes the high
bits).
But that use-case is really exactly what nfs is looking for too, which
is why I was expecting the regular hash_64() to JustWork(tm) for the
nfs case.
Linus
