From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757386AbYLLFM2 (ORCPT ); Fri, 12 Dec 2008 00:12:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754114AbYLLFMJ (ORCPT ); Fri, 12 Dec 2008 00:12:09 -0500 Received: from gw1.cosmosbay.com ([86.65.150.130]:55003 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752955AbYLLFMG convert rfc822-to-8bit (ORCPT ); Fri, 12 Dec 2008 00:12:06 -0500 Message-ID: <4941F26F.5030902@cosmosbay.com> Date: Fri, 12 Dec 2008 06:11:11 +0100 From: Eric Dumazet User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Nick Piggin CC: Andrew Morton , Ingo Molnar , Christoph Hellwig , David Miller , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, "kernel-testers@vger.kernel.org >> Kernel Testers List" , Mike Galbraith , Peter Zijlstra , Linux Netdev List , Christoph Lameter , linux-fsdevel@vger.kernel.org, Al Viro , "Paul E. McKenney" Subject: Re: [PATCH v3 2/7] fs: Use a percpu_counter to track nr_inodes References: <493100B0.6090104@cosmosbay.com> <4941968E.3020201@cosmosbay.com> <200707241130.56767.nickpiggin@yahoo.com.au> In-Reply-To: <200707241130.56767.nickpiggin@yahoo.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [0.0.0.0]); Fri, 12 Dec 2008 06:11:12 +0100 (CET) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nick Piggin a écrit : > On Friday 12 December 2008 09:39, Eric Dumazet wrote: >> Avoids cache line ping pongs between cpus and prepare next patch, >> because updates of nr_inodes dont need inode_lock anymore. >> >> (socket8 bench result : no difference at this point) > > Looks good. > > But.... If we never actually need fast access to the approximate > total, (which seems to apply to this and the previous patch) we > could use something much simpler which does not have the spinlock > or all this batching stuff that percpu counters have. I'd prefer > that because it will be faster in a straight line... Well, using a non batching mode could be real easy, just call __percpu_counter_add(&counter, inc, 1<<30); Or define a new percpu_counter_fastadd(&counter, inc); percpu_counter are nice because handle the CPU hotplug problem, if we want to use for_each_online_cpu() instead of for_each_possible_cpu(). > > (BTW. percpu counters can't be used in interrupt context? That's > nice.) > > Not sure why you said this. I would like to have a irqsafe percpu_counter, I was preparing such a patch because we need it for net-next From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH v3 2/7] fs: Use a percpu_counter to track nr_inodes Date: Fri, 12 Dec 2008 06:11:11 +0100 Message-ID: <4941F26F.5030902@cosmosbay.com> References: <493100B0.6090104@cosmosbay.com> <4941968E.3020201@cosmosbay.com> <200707241130.56767.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andrew Morton , Ingo Molnar , Christoph Hellwig , David Miller , "Rafael J. Wysocki" , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> Kernel Testers List" , Mike Galbraith , Peter Zijlstra , Linux Netdev List , Christoph Lameter , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Al Viro , "Paul E. McKenney" To: Nick Piggin Return-path: In-Reply-To: <200707241130.56767.nickpiggin-/E1597aS9LT0CCvOHzKKcA@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org Nick Piggin a =E9crit : > On Friday 12 December 2008 09:39, Eric Dumazet wrote: >> Avoids cache line ping pongs between cpus and prepare next patch, >> because updates of nr_inodes dont need inode_lock anymore. >> >> (socket8 bench result : no difference at this point) >=20 > Looks good. >=20 > But.... If we never actually need fast access to the approximate > total, (which seems to apply to this and the previous patch) we > could use something much simpler which does not have the spinlock > or all this batching stuff that percpu counters have. I'd prefer > that because it will be faster in a straight line... Well, using a non batching mode could be real easy, just call __percpu_counter_add(&counter, inc, 1<<30); Or define a new percpu_counter_fastadd(&counter, inc); percpu_counter are nice because handle the CPU hotplug problem, if we want to use for_each_online_cpu() instead of for_each_possible_cpu(). >=20 > (BTW. percpu counters can't be used in interrupt context? That's > nice.) >=20 >=20 Not sure why you said this. I would like to have a irqsafe percpu_counter, I was preparing such a patch because we need it for net-next