From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f173.google.com ([209.85.223.173]:39742 "EHLO mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752738AbeBER5Y (ORCPT ); Mon, 5 Feb 2018 12:57:24 -0500 MIME-Version: 1.0 In-Reply-To: References: <1517851938-5892-1-git-send-email-amir73il@gmail.com> From: Linus Torvalds Date: Mon, 5 Feb 2018 09:57:23 -0800 Message-ID: Subject: Re: [RFC][PATCH] : fix end_name_hash() for 64bit long To: Amir Goldstein Cc: Al Viro , Miklos Szeredi , linux-fsdevel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Feb 5, 2018 at 9:51 AM, Amir Goldstein wrote: > > and hash_32_generic() is just __hash_32() with zero shift. Right. But that __hash_32() is very expensive and doesn't help. So the patch as-is doesn't seem to buy anything, and only adds cost. Note that the dentry code is a bit unusual, in that the final shift is done later, in d_hash(). And that takes the _high_ bits of the hash, so unlike a lot of other hash functions, the name hashing doesn't need to try to spread the bits down to the low bits. The intermediate hash value should be fine without any extra spreading. Anyway, we did have numbers at one point. That's what really matters: how good the actual hashing ends up being. So for me to take the patch, I would need to see that it actually improves the hash bucket spreading enough to be worth the cost. Linus