From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: Inode Lock Scalability V7 (was V6) Date: Fri, 22 Oct 2010 04:12:11 +0100 Message-ID: <20101022031211.GI19804@ZenIV.linux.org.uk> References: <1287622186-1935-1-git-send-email-david@fromorbit.com> <20101021050422.GP32255@dastard> <20101021132034.GB13620@amd> <20101021235227.GI12506@dastard> <20101022004540.GA5920@amd> <20101022022010.GG19804@ZenIV.linux.org.uk> <20101022023444.GA6573@amd> <20101022024152.GA6618@amd> <20101022024834.GA6708@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: Received: from zeniv.linux.org.uk ([195.92.253.2]:40796 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164Ab0JVDMM (ORCPT ); Thu, 21 Oct 2010 23:12:12 -0400 Content-Disposition: inline In-Reply-To: <20101022024834.GA6708@amd> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Oct 22, 2010 at 01:48:34PM +1100, Nick Piggin wrote: > On Fri, Oct 22, 2010 at 01:41:52PM +1100, Nick Piggin wrote: > > The locking in my lock break patch is ugly and wrong, yes. But it is > > always an intermediate step. I want to argue that with RCU inode work > > *anyway*, there is not much point to reducing the strength of the > > i_lock property because locking can be cleaned up nicely and still > > keep i_lock ~= inode_lock (for a single inode). > > The other thing is that with RCU, the idea of locking an object in > the data structure with a per object lock actually *is* much more > natural. It's hard to do it properly with just a big data structure > lock. > > If I want to take a reference to an inode from a data structre, how > to do it with RCU? > > rcu_read_lock() > list_for_each(inode) { > spin_lock(&big_lock); /* oops, might as well not even use RCU then */ > if (!unhashed) { > iget(); > } > } Huh? Why the hell does it have to be a big lock? You grab ->i_lock, then look at the damn thing. You also grab it on eviction from the list - *inside* the lock used for serializing the write access to your RCU list.