From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: .. anybody know of any filesystems that depend on the exact VFS 'namehash' implementation? Date: Fri, 2 Mar 2012 02:11:19 +0100 Message-ID: <20120302011119.GA22197@one.firstfloor.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andi Kleen , Linux Kernel Mailing List , linux-fsdevel , Al Viro To: Linus Torvalds Return-path: 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 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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