From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 17/18] fs: icache remove inode_lock Date: Wed, 13 Oct 2010 07:28:27 -0400 Message-ID: <20101013112827.GC16422@infradead.org> References: <1286515292-15882-1-git-send-email-david@fromorbit.com> <1286515292-15882-18-git-send-email-david@fromorbit.com> <20101013072058.GA3121@amd> <20101013072701.GB3121@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Nick Piggin Return-path: Content-Disposition: inline In-Reply-To: <20101013072701.GB3121@amd> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Oct 13, 2010 at 06:27:01PM +1100, Nick Piggin wrote: > I'm happy to help to port the top of the patch set onto changes in > earlier parts of it, but I would like the chance to do this really. I'm > back in action now, so I can spend a lot of time catching up. That's all good and fine, but it's really no reason for delaying getting the most important bits in. RCU path walk is all good and fine, and I'm really looking forward to eventually see it. But the basic inode_lock and dcache_lock splits are fundamental work we need rather sooner than later. Additional candy ontop of that is fine but we'll need a solid base. Also note that having the locking split up, and proper exported APIs instead of growling into dcache internals in various filesystems means that we can start to look into replacing the global inode and dcache hashes much more easily, and having global data structures at least for the dcache is almost as bad as having global locks.