From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751084AbWFRX5t (ORCPT ); Sun, 18 Jun 2006 19:57:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750829AbWFRX5t (ORCPT ); Sun, 18 Jun 2006 19:57:49 -0400 Received: from omx2-ext.sgi.com ([192.48.171.19]:30685 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S1750756AbWFRX5s (ORCPT ); Sun, 18 Jun 2006 19:57:48 -0400 Date: Mon, 19 Jun 2006 09:56:54 +1000 From: David Chinner To: Neil Brown Cc: Jan Blunck , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, akpm@osdl.org, viro@zeniv.linux.org.uk, dgc@sgi.com, balbir@in.ibm.com Subject: Re: [patch 0/5] [PATCH,RFC] vfs: per-superblock unused dentries list (2nd version) Message-ID: <20060618235654.GB2114946@melbourne.sgi.com> References: <20060601095125.773684000@hasse.suse.de> <17539.35118.103025.716435@cse.unsw.edu.au> <20060616155120.GA6824@hasse.suse.de> <17555.12234.347353.670918@cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17555.12234.347353.670918@cse.unsw.edu.au> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 17, 2006 at 08:25:14AM +1000, Neil Brown wrote: > On Friday June 16, jblunck@suse.de wrote: > > On Mon, Jun 05, Neil Brown wrote: > > > > > I understand that this is where problem is because the selected > > > dentries don't stay at the end of the list very long in some > > > circumstances. In particular, other filesystems' dentries get mixed > > > in. > > > > No. The problem is that the LRU list is too long and therefore unmounting > > seems to take ages. > > > > But I cannot see that the whole LRU list needs to be scanned during > unmount. ... > I can see that shrink_dcache_sb could take a long time and should be > fixed, which should be as simple as replacing it with > shrink_dcache_parent; shrink_dcache_anon. But these are not guaranteed to reclaim all the dentries from a given superblock. Yes, they move the dentries to the LRU, but other activity in the system means that they may not get reclaimed during the subsequent calls to prune_dcache() and hence they may live beyond the unmount.... > But I'm still puzzled as to why a long dcache LRU slows down > unmounting. > > Can you give more details? It's not the unmount that slows down - it's the fact that the dcache lock is held for so long that rest of the system halts for time it takes to run shrink_dcache_sb(). We've seen up to 50s to do a (touch fred; rm fred) when the LRU has grown to several million dentries and shrink_dcache_sb() is running. When this happens, it's not uncommon to see every CPU in the machine spinning on the dcache_lock... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group