Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754564AbYJTT2t (ORCPT ); Mon, 20 Oct 2008 15:28:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753189AbYJTT2k (ORCPT ); Mon, 20 Oct 2008 15:28:40 -0400 Received: from fxip-0047f.externet.hu ([88.209.222.127]:60711 "EHLO pomaz-ex.szeredi.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753093AbYJTT2j (ORCPT ); Mon, 20 Oct 2008 15:28:39 -0400 To: cl@linux-foundation.org CC: miklos@szeredi.hu, 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 In-reply-to: <48FCD7CB.4060505@linux-foundation.org> (message from Christoph Lameter on Mon, 20 Oct 2008 14:11:07 -0500) 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> <48FCD7CB.4060505@linux-foundation.org> Message-Id: From: Miklos Szeredi Date: Mon, 20 Oct 2008 21:28:29 +0200 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2192 Lines: 49 On Mon, 20 Oct 2008, Christoph Lameter wrote: > >>> 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. So, isn't it possible to do without get_dentries()? What's the fundamental difference between this and regular cache shrinking? > Those inodes are going to be freed by the reclaim code. Why would > they be busy (unless the case below occurs of course). Case below was brainfart, please ignore. But that doesn't really help: the VFS assumes that you cannot umount while there are busy dentries/inodes. Usually it works this way: VFS first gets vfsmount ref, then gets dentry ref, and releases them in the opposite order. And umount is not allowed if vfsmount has a non-zero refcount (it's a bit more complicated, but the essense is the same). The current SLUB defrag violates this: it gets dentry or inode ref without getting a ref on the vfsmount or the super block as well. This means that the umount will succeed (that's OK), but also the super block will be going away and that's bad. See generic_shutdown_super(). > > 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. Right. Miklos -- 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/