Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754799AbYJTTMY (ORCPT ); Mon, 20 Oct 2008 15:12:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752449AbYJTTML (ORCPT ); Mon, 20 Oct 2008 15:12:11 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:49841 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752303AbYJTTMK (ORCPT ); Mon, 20 Oct 2008 15:12:10 -0400 Message-ID: <48FCD7CB.4060505@linux-foundation.org> Date: Mon, 20 Oct 2008 14:11:07 -0500 From: Christoph Lameter User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Miklos Szeredi CC: penberg@cs.helsinki.fi, nickpiggin@yahoo.com.au, hugh@veritas.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org Subject: Re: SLUB defrag pull request? References: <1223883004.31587.15.camel@penberg-laptop> <1223883164.31587.16.camel@penberg-laptop> <200810132354.30789.nickpiggin@yahoo.com.au> <48F378C6.7030206@linux-foundation.org> <48FC9CCC.3040006@linux-foundation.org> <48FCCC72.5020202@linux-foundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2126 Lines: 52 Miklos Szeredi wrote: >> There is another call to invalidate_mapping_pages() in prune_icache (that is >> where this code originates). No i_mutex and i_alloc. Only iprune_mutex held >> and that seems to be for the protection of the list. So just checking >> inode->i_count would do the trick? > > Yes, that's what I was saying. Ok. Thats easy to do. > >>> The big issue is dealing with umount. You could do something like >>> grab_super() on sb before getting a ref on the inode/dentry. But I'm >>> not sure this is a good idea. There must be a simpler way to achieve >>> this.. >> Taking a lock on vfsmount_lock? But that would make dentry reclaim a pain. > > No, I mean simpler than having to do this two stage stuff. How could it be simpler? First you need to establish a secure reference to the object so that it cannot vanish from under us. Then all the references can be checked and possibly removed. If we do not need a secure reference then the get_dentries() etc method can be NULL. >> We are only interested in the reclaim a dentry if its currently unused. If so >> then why does unmount matter? Both unmount and reclaim will attempt to remove >> the dentry. >> >> Have a look at get_dentries(). It takes the dcache_lock and checks the dentry >> state. Either the entry is ignored or dget_locked() removes it from the lru. >> If its off the LRU then it can no longer be reclaimed by umount. > > How is that better? You will still get busy inodes on umount. Those inodes are going to be freed by the reclaim code. Why would they be busy (unless the case below occurs of course). > And anyway the dentry could be put back onto the LRU by somebody else > between get_dentries() and kick_dentries(). So I don't even see how > taking the dentry off the LRU helps _anything_. get_dentries() gets a reference. dput will not put the dentry back onto the LRU. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/