Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755377Ab0KLReG (ORCPT ); Fri, 12 Nov 2010 12:34:06 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:47829 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754877Ab0KLReF (ORCPT ); Fri, 12 Nov 2010 12:34:05 -0500 MIME-Version: 1.0 In-Reply-To: <20101112064911.GA3775@amd> References: <20101109124610.GB11477@amd> <1289319698.2774.16.camel@edumazet-laptop> <20101109220506.GE3246@amd> <20101112060202.GB3332@amd> <20101112064911.GA3775@amd> From: Linus Torvalds Date: Fri, 12 Nov 2010 09:33:11 -0800 Message-ID: Subject: Re: [patch 1/6] fs: icache RCU free inodes To: Nick Piggin Cc: Nick Piggin , Eric Dumazet , Al Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Dave Chinner Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1951 Lines: 38 On Thu, Nov 11, 2010 at 10:49 PM, Nick Piggin wrote: > > In reality, it's likely to be well under 0.1% in any real workload, even > an inode intensive one. So I much prefer to err on the side of less > complexity, to start with. There just isn't much risk of regression > AFAIKS, and much more risk of becoming unmaintainable too complex. Well, I have to say that if we don't get this lockless path lookup thing merged in the next merge window (ir 38-rc1), I'm going to be personally very disappointed (*). So yes, the "initial complexity" argument is certainly acceptable to me. It does make me suspect something is wrong, though, because quite frankly, the actual accesses to the inode during the lockless walk should be very _very_ controlled anyway. And it's trivial to do a "is this inode still the same one I started with" with zero locking, by just checking that "dentry->d_inode" is the same after-the-fact and checking that the dentry is still hashed. The inode type had better _NOT_ change if the dentry pointer is still there. So even if the type or i_ops changes, none of that should matter in the least. Nobody should _care_. We might get two wildly different results, but we have a trivial way to check whether the inode was stable after-the-fact, and just punt if it wasn't. So it really smells like if this is an issue, there's something wrong going on. Linus (*) To the point where if Al and Dave cannot end up agreeing on something, I'll just instead end up making the executive decision to screw the eternal nay-saying, and just merging your series. So just a heads-up guys: healthy discussion is fine, but obstructionism will _not_ work. -- 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/