From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [RFC v4 Patch 0/4] fs/inode.c: optimization for inode lock usage Date: Sat, 22 Sep 2012 08:49:12 +1000 Message-ID: <20120921224912.GA20960@dastard> References: <1348219866-1799-1-git-send-email-yan@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: viro@zeniv.linux.org.uk, dchinner@redhat.com, hch@infradead.org, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Guo Chao Return-path: Content-Disposition: inline In-Reply-To: <1348219866-1799-1-git-send-email-yan@linux.vnet.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Sep 21, 2012 at 05:31:02PM +0800, Guo Chao wrote: > This patchset optimizes several places which take the per inode spin lock. > They have not been fully tested yet, thus they are marked as RFC. Inodes are RCU freed. The i_lock spinlock on the i_state field forms part of the memory barrier that allows the RCU read side to correctly detect a freed inode during a RCU protected cache lookup (hash list traversal for the VFS, or a radix tree traversal for XFS). The i_lock usage around the hahs list operations ensures the hash list operations are atomic with state changes so that such changes are correctly detected during RCU-protected traversals... IOWs, removing the i_lock from around the i_state transitions and inode hash insert/remove/traversal operations will cause races in the RCU lookups and result in incorrectly using freed inodes instead of failing the lookup and creating a new one. So I don't think this is a good idea at all... Cheers, Dave. -- Dave Chinner david@fromorbit.com