Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422731Ab3CVTnw (ORCPT ); Fri, 22 Mar 2013 15:43:52 -0400 Received: from mail-vb0-f52.google.com ([209.85.212.52]:41139 "EHLO mail-vb0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755110Ab3CVTnv (ORCPT ); Fri, 22 Mar 2013 15:43:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <20130321233630.GE21522@ZenIV.linux.org.uk> <20130322001257.GH21522@ZenIV.linux.org.uk> <20130322012208.GJ21522@ZenIV.linux.org.uk> <20130322014037.GK21522@ZenIV.linux.org.uk> <20130322043715.GL21522@ZenIV.linux.org.uk> <20130322051817.GM21522@ZenIV.linux.org.uk> Date: Fri, 22 Mar 2013 12:43:50 -0700 X-Google-Sender-Auth: -LdiSNepmMgxGL1m2xRBo-HEzUk Message-ID: Subject: Re: [CFT] Re: VFS deadlock ? From: Linus Torvalds To: Al Viro Cc: Dave Jones , Linux Kernel , "Eric W. Biederman" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2077 Lines: 42 On Thu, Mar 21, 2013 at 10:33 PM, Linus Torvalds wrote: > > And I wonder how big of a deal the aggressive dentry deletion is. > Maybe it's even ok to allocate/free the inodes all the time. The whole > "get the inode hash lock and look it up there" can't be all that > wonderful either. It takes the inode->i_lock for each entry it finds > on the hash list, which looks horrible. I suspect our slab allocator > isn't much worse than that, although the RCU freeing of the inodes > could end up being problematic. I tested this out by just having a process that keeps stat'ing the same /proc inode over and over and over again, which should be pretty much the worst-case situation (because we will delete the dentry after each stat, and so we'll repopulate it for each stat) The allocation overhead seems to be in the noise. The real costs are all in proc_lookup_de() just finding the entry, with strlen/strcmp being much hotter. So if we actually care about performance for these cases, what we would actually want to do is to just cache the dentries and have some kind of timeout instead of getting rid of them immediately. That would get rid of the lookup costs, and in the process also get rid of the constant inode allocation/deallocation costs. There was also some locking overhead, but that's also mainly dentry-related, with the inode side being visible but not dominant. Again, not immediately expiring the dentries would make all that just go away. Regardless, the patch seems to be the right thing to do. It actually simplifies /proc, seems to fix the problem for Dave, and is small and should be trivial to backport. I've committed it and marked it for stable. Let's hope there won't be any nasty surprises, but it does seem to be the simplest non-hacky patch. Linus -- 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/