From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758097Ab2CBBLW (ORCPT ); Thu, 1 Mar 2012 20:11:22 -0500 Received: from one.firstfloor.org ([213.235.205.2]:58817 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757942Ab2CBBLV (ORCPT ); Thu, 1 Mar 2012 20:11:21 -0500 Date: Fri, 2 Mar 2012 02:11:19 +0100 From: Andi Kleen To: Linus Torvalds Cc: Andi Kleen , Linux Kernel Mailing List , linux-fsdevel , Al Viro Subject: Re: .. anybody know of any filesystems that depend on the exact VFS 'namehash' implementation? Message-ID: <20120302011119.GA22197@one.firstfloor.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 01, 2012 at 05:01:52PM -0800, Linus Torvalds wrote: > On Thu, Mar 1, 2012 at 4:46 PM, Andi Kleen wrote: > > > > There should be generally better modern general hash algorithms around, > > like murmur, cityhash or snoopy. Perhaps even the fnv we have in tree, > > but it's somewhat dated by know. > > > > They all have larger code, but if it's really that hot it would be worth > > it. > > The quality of our hash function really doesn't seem to be the issue. With better I meant mainly faster in cycles. e.g. CityHash claims upto ~6 bytes/cycle. That's extreme and may need the SSE versions, but there are non SSE variants e.g. in spooky that are somewhat competive. Are you anywhere near that with your hash function? Partly they get that from unrolling, but there are also lots of other tricks. Also BTW if we had better hash functions (in mixing) we could do smaller hash tables. -Andi