From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [PATCH 03/18] fs: Implement lazy LRU updates for inodes. Date: Sat, 16 Oct 2010 18:56:58 +1100 Message-ID: <20101016075658.GN19147@amd> References: <1286928961-15157-1-git-send-email-david@fromorbit.com> <1286928961-15157-4-git-send-email-david@fromorbit.com> <20101013133213.GC5263@infradead.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: Christoph Hellwig Return-path: Content-Disposition: inline In-Reply-To: <20101013133213.GC5263@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Oct 13, 2010 at 09:32:13AM -0400, Christoph Hellwig wrote: > > */ > > redirty_tail(inode); > > - } else if (atomic_read(&inode->i_count)) { > > - /* > > - * The inode is clean, inuse > > - */ > > - list_move(&inode->i_list, &inode_in_use); > > } else { > > - /* > > - * The inode is clean, unused > > - */ > > - list_move(&inode->i_list, &inode_unused); > > + /* The inode is clean */ > > + list_del_init(&inode->i_list); > > + inode_lru_list_add(inode); > > Just noticed this when reviewing a later patch: why do we lose the > i_count check here? There's no point in adding an inode that is still > in use onto the LRU - we'll just remove it again once we find it > during LRU scanning. I did it this way because we're already holding the lock. But with the inode and lru lists locked seperately in a subsequent patch, it is better to check the count, I agree.