[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgqo0xdOXQSj2uX7Zkdn9jYvn=vapmt4XGaSP6B=ZAmqw@mail.gmail.com>
Date: Wed, 30 Mar 2022 13:11:02 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Trond Myklebust <trondmy@...merspace.com>
Cc: "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Please pull NFS client changes for Linux 5.18
On Wed, Mar 30, 2022 at 1:02 PM Trond Myklebust <trondmy@...merspace.com> wrote:
>
> My main worry was that hash_64() would have too many collisions.
So as you found out, hash_64() is actually a fairly good hash despite
being very simple.
In fact, with an input of just one word, it's generally hard to do
much better. I'm obviously not claiming it's a _cryptographic_ hash,
but compared to the usual "xor and shift a few times", it really
shouldn't be too bad.
And that's really what xxhash() does anyway.
I think the reason to use xxhash() would be if you have a noticeably
bigger input, or some truly special cases.
But for a single word, and then not even using very many of the
resulting bits, our regular family of 'hash()' routines really should
generally be perfectly fine. It should spread and mix the input bits
competently.
Linus
Powered by blists - more mailing lists