Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755381Ab0KLEtP (ORCPT ); Thu, 11 Nov 2010 23:49:15 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:40340 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755204Ab0KLEtO (ORCPT ); Thu, 11 Nov 2010 23:49:14 -0500 MIME-Version: 1.0 In-Reply-To: References: <20101109124610.GB11477@amd> <1289319698.2774.16.camel@edumazet-laptop> <20101109220506.GE3246@amd> From: Linus Torvalds Date: Thu, 11 Nov 2010 20:48:38 -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 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: 974 Lines: 22 On Thu, Nov 11, 2010 at 5:24 PM, Nick Piggin wrote: > > So this is really not a "oh, maybe someone will see 10-20% slowdown", or even > 1-2% slowdown. You ignored my bigger issue: the _normal_ way - and the better way - to handle these thingsis with SLAB_DESTROY_BY_RCU. So what are the advantages of using the inferior approach? I really don't see why you push the whole "free the damn things individually" approach. We've had experience with that, and it's resulted in long RCU queues with memory being held up in queuing etc (hopefully we've improved on the queuing issues with RCU itself, but..) So the thing is, SLAB_DESTROY_BY_RCU is just the RightThing(tm). Why fight it? 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/