From mboxrd@z Thu Jan 1 00:00:00 1970 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 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