From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: Word-at-a-time dcache name accesses (was Re: .. anybody know ofany filesystems that depend on the exact VFS 'namehash' implementation?) Date: Sun, 4 Mar 2012 05:31:07 +0100 Message-ID: <20120304043107.GC22197@one.firstfloor.org> References: <201203041127.IDI56216.FHOQMOVLtOFSJF@I-love.SAKURA.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: torvalds@linux-foundation.org, andi@firstfloor.org, hpa@zytor.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk To: Tetsuo Handa Return-path: Received: from one.firstfloor.org ([213.235.205.2]:60374 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754354Ab2CDEbI (ORCPT ); Sat, 3 Mar 2012 23:31:08 -0500 Content-Disposition: inline In-Reply-To: <201203041127.IDI56216.FHOQMOVLtOFSJF@I-love.SAKURA.ne.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Mar 04, 2012 at 11:27:01AM +0900, Tetsuo Handa wrote: > A passer-by's mumble. > > We are discussing about systems with huge "struct dentry" instances where > selecting a hash list based on "struct qstr"->hash cannot effectively narrow > down candidates to compare, aren't we? This is effectively a simple bloom filter. Would be only worth it if longer hash chains are common. And if that's the case we should probably have either a larger table or a better hash (or both) -Andi