From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [PATCH 04/21] fs: Implement lazy LRU updates for inodes Date: Thu, 21 Oct 2010 21:07:06 +1100 Message-ID: <20101021100706.GA9797@amd> References: <1287622186-1935-1-git-send-email-david@fromorbit.com> <1287622186-1935-5-git-send-email-david@fromorbit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Dave Chinner Return-path: Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:36063 "EHLO ipmail05.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751307Ab0JUKHN (ORCPT ); Thu, 21 Oct 2010 06:07:13 -0400 Content-Disposition: inline In-Reply-To: <1287622186-1935-5-git-send-email-david@fromorbit.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Oct 21, 2010 at 11:49:29AM +1100, Dave Chinner wrote: > } else { > /* > - * The inode is clean, unused > + * The inode is clean. If it is unused, then make sure > + * that it is put on the LRU correctly as iput_final() > + * does not move dirty inodes to the LRU and dirty > + * inodes are removed from the LRU during scanning. > */ > - list_move(&inode->i_list, &inode_unused); > + list_del_init(&inode->i_list); > + if (!atomic_read(&inode->i_count)) > + inode_lru_list_add(inode); This "optimisation" is surely wrong. How could we have no reference on the inode at this point? > -static int can_unuse(struct inode *inode) > -{ > - if (inode->i_state) > - return 0; > - if (inode_has_buffers(inode)) > - return 0; > - if (atomic_read(&inode->i_count)) > - return 0; > - if (inode->i_data.nrpages) > - return 0; > - return 1; > -} Avoiding the reclaim optimisation? As I said, I noticed some increased scanning in heavy reclaim from removing this.