From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [PATCH 06/17] fs: icache lock lru/writeback lists Date: Sat, 16 Oct 2010 18:55:27 +1100 Message-ID: <20101016075527.GK19147@amd> References: <1285762729-17928-1-git-send-email-david@fromorbit.com> <1285762729-17928-7-git-send-email-david@fromorbit.com> <20100929215240.feb118f3.akpm@linux-foundation.org> 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: Andrew Morton Return-path: Content-Disposition: inline In-Reply-To: <20100929215240.feb118f3.akpm@linux-foundation.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Sep 29, 2010 at 09:52:40PM -0700, Andrew Morton wrote: > On Wed, 29 Sep 2010 22:18:38 +1000 Dave Chinner wrote: > > > The inode moves between different lists protected by the inode_lock. Introduce > > a new lock that protects all of the lists (dirty, unused, in use, etc) that the > > inode will move around as it changes state. As this is mostly a list for > > protecting the writeback lists, name it wb_inode_list_lock and nest all the > > list manipulations in this lock inside the current inode_lock scope. > > All those spin_trylock()s are real ugly. They're unexplained in the > changelog and unexplained in code comments. > > I'd suggest that each such site have a comment explaining why we're > resorting to this. They're really a side effect of how I'm building up the locking in steps and then streamlining it in steps. Most of them disappear or get much improved as inode removal, rcu, etc greatly help with lock ordering. The intermediate steps are not supposed to be so pretty, so much as an easily verifiable "ok, we have enough locking to cover what inode_lock used to be protecting".